Re: Swing/AWT concurrency

Correct, that can hang.

I was waiting when we will start reducing a big claim of a variety of
situations that confuse experts, to a simple claim of a broken condition
wait.

I suppose the experienced programmers understand "condition wait" concept?

Alex

On Wed, 21 Jul 2021, 00:18 Brian S O'Neill, <[email protected]> wrote:

> 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