March 13, 2012
Java: use faster nonsynchronized ByteArrayOutputStream
Seen here http://javatechniques.com/blog/faster-deep-copies-of-java-objects/ an advice to use unsynchronized version of ByteArrayOutputStream which is faster than default java.io synchronized version.
It seems to make sense! But I have not yet benchmarked it.
It seems to make sense! But I have not yet benchmarked it.
Labels: ByteArray, java, optimization, synchronized
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
