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

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?
>

Just a second. The compiler is not in a position to decide what the
programmer meant. Some loops prevent progress upon an incorrect condition.
Some loops introduce delays. Which one did the programmer mean? How does
this differ from a case where the programmer simply made a mistake and the
condition is not meant to become true?

I have a question, too. Will a programmer not use j.u.c.locks.Condition or
just Object.wait in the body of the loop? Will the programmer not follow
the recommendations you quote, if they have no time to learn the subject
and become comfortable juggling volatiles?



> > 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.
>

Sure thing. But as anyone who tried to convince Agda that the function does
what its specification says, can tell you, it does make mistakes harder to
make, but does not make programming correctly easier.

In Java we are in the situation where there is no formal proof that your
program makes no sense. So it is easy to create nonsense, and impossible to
automatically check that something is nonsense.


Alex


Gregg Wonderly
>

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