Java Concurrency (&c)

(Note: I've cribbed this from my doctoral dissertation. I tried to edit it heavily to ease up on the mangled academic syntax required by thesis committees, but I may have missed some / badly edited in places. Let me know if there is something confusingly written or just plain confusing, and I'll try to untangle it.) There are these three concepts, you see. And they are fundamental to correct concurrent programming. When a concurrent program is not correctly written, the errors tend to fall into one of the three categories: atomicity , visibility , or ordering . Atomicity deals with which actions and sets of actions have indivisible effects. This is the aspect of concurrency most familiar to programmers: it is usually thought of in terms of mutual exclusion. Visibility determines when the effects of one thread can be seen by another. Ordering determines when actions in one thread can be seen to occur out of order with respect to another. Let's talk about t

Here's a question I get a lot. Is the following code snippet "thread safe"? volatile int v = 0; Thread 1: v++; Thread 2: v--; The question asks what the possible results of this code are; the questioners usually want the answer "v can only be 0 after this code is run". This isn't the way it works! If you do an increment of a volatile integer, you are actually performing three separate operations: Read the integer to a local. Increment the local. Write the integer back out to the volatile field. So what you really have is this: volatile int v = 0; Thread 1: r1 = v; r2 = r1 + 1; v = r2; Thread 2: r3 = v; r4 = r3 - 1; v = r4; So, if Threads 1 and 2 both read v and see the value 0, then Thread 1 will write 1 to it and Thread 2 will write -1 to it. You are not guaranteed to see the value 0! If you want an atomic increment (or decrement), you have to use the java.util.concurrent.atomic classes , which allow you to create object that represent numbers that can

Those of you who attend JavaOne will know Josh Bloch, Neal Gafter and Bill Pugh's series of highly entertaining Java Puzzlers. Now, for the first time, one of these talks is available to people who are not JavaOne attendees: Josh and Bill gave this year's Java Puzzlers talk at Google. I wouldn't dare spoil the fun by posting any of the puzzlers or their solutions (although Josh blows the surprise on one of them). This is definitely worth the time of anyone who does any programming in Java (and has 1 hour and 14 minutes to kill). I would be remiss if I didn't point out the Java puzzlers web site , where a book is available.

This is another one of those Google talks. This time, it is Mark Moir talking about the transactional memory work he is doing at Sun . It is very useful if you are interested in listening to a strong statement about building hybrid software / hardware transactional memory systems. As someone who has written papers on transactional memory systems, I am still unconvinced that they are the panacea that some of their supporters seems to claim (not Mark, as far as I can tell). Plusses: a) Deadlock avoidance (if the semantics are chosen correctly), b) More easily programmed non-blocking algorithms (if the system is implemented incredibly carefully). Minuses: a) They are still prey to the other problems of parallel shared memory systems, like data races and atomicity problems, b) I have yet to hear a convincing argument as to what their actual semantics should be, especially as regards nested transactions, but even for ordinary transactions. One language design (which shall remain nameles