July 27, 2009
[life] iphone -> iSkype-on
Yesterday I tried to call through wifi via skype using iphone client. Works great, talked for more than 15 minutes and quality is just like when using GSM! Also tried to install the Android skype client, but is said that I MUST enter my phone number and it will (WTF?!) be used when calling (all calls are paid, it said! callback?). Seems that Skype beta in Android is very strange thing: it cannot use 3G/Wifi connection for free skype2skype calls. Yes, just found quote from comments from here: http://share.skype.com/sites/skypegear/2009/01/video_skype_lite_on_android.html
and more:
This is it. iPhone is better :-)
Sad that receiving any phone calls, even from a skype caller, skype credit is used.and more:
No calls can be made, no free calls received even when in WI-FI spot. This application is not ready for prime time ... If I wanted to IM, I would use another application. Please make Skype like it is on computers. Free calls computer-to-computer (or phone-to-skype_contact) over wifi or carrier's data plan.
Else is is useless.This is it. iPhone is better :-)
July 26, 2009
[Java] The difference between volatile and synchronized
Quote from java.util.concurrenct package docs:
A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.Labels: critical section, java, synchronized, volatile
July 24, 2009
[J2ME] deadlock in canvas.paint, lcdui
If you need to have a critical section in Canvas.paint() override, double-check that you do not lock in same monitor when calling myCanvas.repaint(). Problem exists in this some specific configuration, when you have 2 threads. In [1, main for example] you do:
display.setCurrent(myCanvas); and in [2, newly created] you call:
myCanvas.repaint() in same critical section as in your paint() impl.
I had deadlock in this case, at least in some LCDUI implementations. The reason is that MIDP usually have its own critical section in setCurrent() (when calling paint() for the first time) and in repaint() (when adding repaint event into queue), so it cannot both add repaint request into queue and enter your paint()'s your critical section. Deadlock. So be careful ;-)
display.setCurrent(myCanvas); and in [2, newly created] you call:
myCanvas.repaint() in same critical section as in your paint() impl.
I had deadlock in this case, at least in some LCDUI implementations. The reason is that MIDP usually have its own critical section in setCurrent() (when calling paint() for the first time) and in repaint() (when adding repaint event into queue), so it cannot both add repaint request into queue and enter your paint()'s your critical section. Deadlock. So be careful ;-)
Labels: concurrency, critical section, deadlock, j2me, java, lcdui, multithreading, programming, synchronized, thread
[office2007] ...Application configuration incorrect...
Some time ago my office 2007 stopped work after I uninstalled custom Windows Search 4 component of Windows. Reinstalling of Office didn't work (actually, even uninstaller/installer didn't work, both have errors!).
If you have same problem, here's solution: (re)install MS C++ 2005 runtime.
If you have same problem, here's solution: (re)install MS C++ 2005 runtime.
