Re: Are there real use cases with the Java access modes?

> On Jul 22, 2021, at 4:38 AM, Alex Otenko via Concurrency-interest <[email protected]> wrote:
> 
> Even though we've beaten this topic to death several times over, and perhaps some already find the discussion overlong, let me point out one last observation.
> 
> Your claim about the level of ignorance is incompatible with your own view of the principle of least astonishment. Here's how.
> 
> The "problematic" hoist can happen only if the loop body has no interaction with the other threads, *and* there is no modification of the loop variable inside the loop body. So, if the programmer, no matter how naive, has not put any expression that may modify the loop exit condition, he either is not surprised at the loop being infinite, or is aware of concurrency - the condition being updated by some mechanism that us not described by the syntactic order of expressions.

It’s not concurrency that I am talking about specifically around ignorance.  It’s volatile vs non-volatile.  Yes, they may know that some how the listener/notification/callback is involved to set done = true.  But the implementation of how that happens, is not directly visible.  Specifically, they are using some “platform” or “package” of software that has all these APIs that provide for listener/callback/notification and how those things are invoked and with what thread, and what HB conditions exist, including fences, is not in any code they write explicitly.  Thus, they are not thinking about this nor have any real knowledge about what to think about, nor what to exhaustively search through to discover why their loop is not exiting.

The web page I included in an earlier post at .mil demonstrates that there are a huge number of "non-volatile by default" considerations that are thought to be extremely important to know about.  Had non-volatile been the default, with a ‘local’ or ‘unshared’ keyword used instead, we’d have a whole different set of APIs that were created around efficient sharing of data, with hoisting and the lot being explicitly described by the software keywords, constructs and architecture.  It’s that explicit designation of behavior that would make it so much easier to know what was going to happen around optimizations and performance improvements.  

For me, there is no way to look at a class with class level variables and not conclude that each of those values is shared across 1 or more methods as long lived values.  The point of them existing at that declaration level, is to make them persistent across method calls (shared access by one or more threads at any moment).  This is why I keep suggesting that this behavior of non-sharing/non-volatile behavior, by default, for class level values is not really making sense to the whole notion of Java being a multi-threaded language.  When you use multiple threads, you either need to distribute work for performance or isolate work for simplified concurrency as the AWT event queue does.  The listeners are the path between the two thread groups involved, and sharing data values is trivially done in listener method implementations.  That’s the mistake people readily make.

I am sorry that you find my argument inconsistent or imperfect.  I’d like you to not be lured down that path of argument, because then I feel like I have to repeat myself with different words because you’re distracted by my word choices or are logically bothered by them at any rate.

> Granted, a novice cannot put it in such words, but still, you can no longer insist that they are blissfully unaware of concurrency, because for the thing to work, they have to rely on it in their minds.

Again, its not really “concurrency” but the fact that “volatile” is not the default and non-volatile values create the lack of sharing across threads as a seamless form of communications.  You have to thus know about volatile to make references work across thread groups.

Because this is about a non-volatile field reference, we can’t event change the declaration to:

AtomicBoolean done = new AtomicBoolean();

I.e. even this seemly concurrency ready class can’t solve the problem of reference hoisting.  We have to know that volatile is required, and it’s that specific knowledge that I want to keep the conversation focused on.

> There may be some surprise, but that is the surprise of a learner finding out how it works, not a programmer that is surprised at the thing not working as written - because the interaction bit is *not* written.
> 
> 
> Alex
> 

Gregg Wonderly

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