Swing/AWT concurrency

This is a continuation of the "Are there real use cases with the Java 
access modes?", but in a separate discussion thread to maintain focus on 
what I feel is the crux of the matter.

Gregg pointed out a potential problem that can affect new Java users 
when writing desktop applications. In particular, one thread can set a 
shared "isDone" field, and another thread might never observe this. In 
practice, the specific example which was provided wouldn't actually have 
a problem, but knowing why this is the case isn't something that a new 
Java user would have any knowledge of. In other languages/frameworks, 
users don't need to understand concurrency except as an advanced topic.

The suggested solution is to require that all fields be volatile as 
default. This naturally causes a knee-jerk reaction to anyone who wants 
the Java platform to be concurrent and highly efficient. And for those 
of us who mostly write server-side applications, we don't understand why 
this change is needed at all. After all, there's a bunch of modern 
async/task scheduling frameworks available that allow new users to write 
safe, efficient, and completely non-surprising programs.

New users of Swing/AWT don't have this luxury. And to them, Java == 
Swing, and so any problems in Swing are equivalent to problems in Java 
itself.

Would declaring all fields as volatile actually fix Swing? Not really. 
Consider the case in which one thread does this:

  isDone = true;
  doneMessage = "all done!";

Both fields are volatile, and both are thus visible to other threads. 
Except what I did is wrong, and it's not obvious to a new user. In their 
head, they think, "this task is done, and the message is 'all done'". So 
naturally the code should be written the same way. In almost all cases, 
this works just fine. Randomly it fails, and now you have to explain to 
the new user the concepts of concurrency, sequential consistency, etc.

If Swing/AWT was designed around a "pure" event loop, then all tasks run 
atomically, and so the order in which fields are assigned isn't 
relevant. They don't need to be volatile either. If the event loop 
implementation wants to use multiple threads, then it's responsible for 
using the correct thread-safe constructs and memory barriers to prevent 
strange issues from cropping up.

Modern frameworks exist on the server side to do just this, but have 
they been adapted for writing desktop apps? Is there an alternative to 
Swing/AWT? If not, my hope is that someone reading this becomes inspired 
to write such a thing. In the past, this seemed quite scary because it 
would likely involve a bunch of JNI coding. Hopefully the Panama project 
will take the sting out of this.

By the way, I know very little about "real world" Swing applications. My 
understanding of the issues might be wrong, so please be nice!
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest