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

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.

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.

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


On Wed, 21 Jul 2021, 16:26 Gregg Wonderly, <[email protected]> wrote:

>
>
> > On Jul 21, 2021, at 4:11 AM, Alex Otenko via Concurrency-interest <
> [email protected]> wrote:
> > The principle of least astonishment is misapplied, too. Astonishment to
> whom?
>
> The programmer is surprised by an optimization that happens at one point
> in the code due to the relationship and exact nature of code elsewhere in
> the block.  Automated hoisting of references is certainly a great
> optimization for things that are being computed with, but a ’truth’ or
> ‘control’ statement implies that mutation would have to happen.  In the
> very specific case of a loop, would the programmer really be purposefully
> creating an infinite loop with an expression/condition involving a
> non-volatile, class level value reference?
>
> > In C all loops terminate, so a C programmer may be astonished that the
> loop you gave as an example does anything at all, if we throw away
> everything out of the loop body. A Python or Javascript programmer may be
> astonished that that loop ever terminates, because it never yields control
> to a routine that mutates the flag.
>
> Depending on ones background, you could be used to something like green
> threads of old.  You could just be guessing that there is an
> interrupt/timer thing that calls out to other code like the V8 runtime does.
>
> > A Rust programmer may be surprised that it compiles - mutability is not
> a given.
>
> And this is more precisely the type of thing that I am trying to speak
> to.  I don’t know a lot about Rust, because I haven’t been able to make
> time to dive in and use it for something significant.  But my casual
> knowledge of it, informs me that people are actually trying to make safe
> software systems by eliminating all of the things that “runtime”,
> “compiler” and “extensions” to software systems can hide form the user and
> invalidate their software without them knowing it.
>
> If the compiler is going to hoist a value, and it’s part of a control
> statement that would be invalidated by the hoist, it seems like warning the
> developer of the mis-declaration or use of concurrent access might be
> prudent so that they can understand what is being overlooked in the current
> software design.  What would happen to large java applications if the java
> compiler did this today?  Would we find bugs?  I am going to bet that we
> would find lots of non-volatile use that is not valid, technically, but
> works practically because of the compiler not being able to reach a
> conclusion allowing it to hoist the read.  So, due to the use of fences for
> so many other things, there is an implicit cache coherency state that
> allows a write to be read across thread boundaries and everyone is happy
> because all tests past.
>
> Gregg Wonderly
>
>
>

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