Re: Swing/AWT concurrency

Hello,

My Experience as a real world swing developer: I know that I have to 
respect multithreading, and if I see a race condition, I change it. 
Usually using SwingUtililities.inokeLater()/ 
Executer.execute()/Future.cancel(), volatile/atomics are almost never 
needed.

The curent state can be simplified for the average developer (me) as: If 
it is shared between Threads, it needs some sort of synchronization. 
Always. If the jvm would prevent "hoisting" it would make judging the 
"correctness" of a code become a mess. I would have to use way to much 
of my limited brain to tell if the race condition is covered by 
"hoisting-prevention" or if its an other race condition that is not 
covered. And/Or I still have to tell everyone to make their fields 
volatile, even if it doesn't do anything anymore and everyone becomes 
even more confused about how multithreading works.

So the usecase Greg presented looks like this: theres a loop, and the 
condition is changed from another thread. That is indeed a real world 
scenario. But in your example there is only one field "done" for which 
you want protection. But in any real usecase there will be more fields. 
So protecting "done", even if possible would just cause more confusion 
later on: is "paused" safe to acess in this way? is "input"? If yes/no 
why? it worked with done before.

while(!done){

if (!paused){

  evaluate(input)

}

}

So in conclusion multithreading simply requires some extra work from the 
developer. Java and also Swing/AWT do a good job providing usefull 
tools. Adding some training wheels seems like a miss to me, because its 
not transparent when the training wheels are on/off and how much they 
actually do.

Best regards,

Thorsten


_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest