April 1, 2011
Java 5/6: Java thread priority problem and workaround
Endre Stølsvik has very detailed research and explanation along with workaround to a problem of broken thread priorities in linux in his blog:
Linux Java Thread Priorities workaround
The kind of situation when you'd like to have priority changed is accepting socket thread under high load (or, of course, a DoS attack ;-) ), or GUI dispatch thread.
BTW, my opinion for running java server-side is strictly solaris-based server, if you can afford it. At least you won't have OS LWP creation overhead for each java thread you start.
I had never tried opensolaris for java deployment, but it seems like just a different build of same beast. Did you?
Linux Java Thread Priorities workaround
The kind of situation when you'd like to have priority changed is accepting socket thread under high load (or, of course, a DoS attack ;-) ), or GUI dispatch thread.
BTW, my opinion for running java server-side is strictly solaris-based server, if you can afford it. At least you won't have OS LWP creation overhead for each java thread you start.
I had never tried opensolaris for java deployment, but it seems like just a different build of same beast. Did you?
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
