Re: Swing/AWT concurrency

I was able to reproduce the problem by changing the example code to have 
an empty loop body. It now looks like this:

   while (!done) {}
   tm.setText("" + new java.util.Date());

A new user might not understand the benefit of adding the sleep in the 
loop, but adding that back in does prevent hoisting.

I don't think the problem is totally made up. I've worked with new and 
experienced programmers who make mistakes like this, and it's not at all 
obvious why this is a problem.


On 2021-07-20 02:38 PM, Alex Otenko wrote:
> I think the problem is totally made up. You can't be using Swing, and 
> not know about threads. Thread safety clauses are all over documentation 
> for components. The hoist that Gregg has an issue with can happen only 
> if non-thread-safe methods are used. Other methods are likely using 
> locks inside, so even though not synchronized properly, the hoisting in 
> question simply cannot happen.
> 
> I was hoping to see a working example that shows otherwise.
> 
> Alex
> 
> On Tue, 20 Jul 2021, 21:47 Brian S O'Neill via Concurrency-interest, 
> <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     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]
>     <mailto:[email protected]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest