Concurrency

List of Concurrent Java Programs:
Just wanted to let you all know officially that I have started a page on my site where I list a bunch of concurrent programs written in Java. The idea is that they may be useful for my own research, and so far it has been hard finding large lists of concurrent programs so that I could pick out one actually relevant for my work. Hopefully this can help change that problem, except that there are only three entries so far... Dig the gnar-gnar CSS while you're at it!

Wait/Notify:
While I'm on the subject of Java concurrency, something came up twice on Friday that I wanted to bring up again; wait/notify. As you may know, Java provides monitors as its built-in all-purpose synchronization primitive. These monitors provide both locking, for mutual exclusion, and wait/notify, for thread synchronization. Other than busy-waiting and thread join, the only means by which one can cause a thread to hold in Java is to call wait and then wait around for another thread to call notify on that same object. Both a research colleague and a paper written by my advisor claimed that wait/notify are rarely used in Java programs. While this certainly may be true, does this imply that most concurrent code written in Java only needs mutual exclusion primitives? What about things like thread barriers, and other thread-ordering devices? Don't people need monitors for those sorts of things?

Performance Tension:
One strange sensation I encountered occurred while attempting to write a concurrent dataflow analysis for the Crystal analysis framework, a Java analysis framework written in Java. There was a point where I found an obvious performance problem, but didn't want to fix it, deciding instead to wait until the program itself actually showed poor performance. This action itself caused me some pause. This action was undoubtedly caused by the phrase that has been ingrained in my subconscious, "premature optimization is the root of all evil." But of course I was busy implementing a concurrent library class whose whole point (ostensibly) was to increase analysis performance. It at least made me realize that there is some tension between what we are always taught about optimization, that it is a discussion best saved until the end of the day, and concurrency, which often permeates the architecture of the program itself. In fact the changes necessitated some global restructuring of the program. "Interesting," is all I could really conclude.