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

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

Sounds like a job for a linter.  For easier cases, an easy PMD rule will
catch such a problem.  For harder cases, the PMD rule will need to traverse
the call tree to see if a thread executing the loop could change the
field.  If not, flag a problem to the programmer.

With such a rule in place, an advanced programmer might write an infinite
loop but PMD will flag the issue and the programmer will learn.  When the
code is changed in the future and this creates an infinite loop, PMD will
flag a problem.

In fact, PMD's rules catch so many mistakes that beginner programmers can
quickly become better programmers.  I work with a bunch of programmers that
have not written production-level code for more than a decade.  I find a
lot of problems during code reviews.  I then write PMD rules to catch
almost all of these problems automatically.  The code quality I see in code
reviews is much better now.  During code reviews, I spend less time
flagging simple mistakes and more time catching deep problems.

On Wed, Jul 21, 2021 at 9:30 AM Gregg Wonderly via Concurrency-interest <
[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
>

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