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

> On Jul 22, 2021, at 2:15 PM, Joe Bowbeer via Concurrency-interest <[email protected]> wrote:
> 
> In my 20+ years of reviewing Java code, my best indicator (red flag) for the presence of bugs has been the existence of synchronized methods and/or volatile fields.
> 
> Programming concurrency at this low level (in Java) is for experts only; whenever mere mortals try it, I can almost guarantee that I will find a bug.

The basic issue is that any mutating value, whether it’s a native type or an object reference, when shared across threads, is going to require volatile or synchronized access control, to make it’s use work within a loop, or multiple consecutive accesses in the same block when reference/value hoisting is possible.  For me, this is the “giant problem”.  To make simple “sharing” possible, you have to know that volatile/synchronized is imperative, but only is the case of “multiple” references (loop or within a block) does it become a visible roadblock.  It works everywhere else, because the compiler can’t say “only one thread does this” when a block has “one" reference to a class field, and thus a hoist doesn’t “occur” right?

In the case of a block with multiple, consecutive access to the same reference/value, there’s a mixed set of circumstances involved where many actions that would require a new reference to be retrieved, the JIT does this because it sees an HB event.

> The only hope for beginners is to leverage single-threaded subsystems and higher-level concurrency patterns.

This is what many people rely on, but as my example “how-to not do bad things” linked document shows, there are countless examples, where such patterns must be used and codified in reusable ways.  The problem with “random” java written by beginners is that it’s possible to experience problems because you aren’t using a concurrency proficient platform.

> In summary, making volatile the default would make it harder for me to find bugs 😀

I can chuckle at that, but it’s hard to have a straight face about it! :-)

Gregg Wonderly

> 
> On Thu, Jul 22, 2021 at 7:40 AM Nathan Reynolds via Concurrency-interest <[email protected] <mailto:[email protected]>> wrote:
> JIT has to decide if the loop condition can be hoisted.  JIT halts the hoisting optimization even on the world "full of nontrivial things"... and if not the JIT team gets a bug to fix.  Hence, I suspect JIT is conservative on how deep it tries to examine to figure out if the condition can be hoisted.  I suspect that when JIT does not know what the destination is (e.g. Runnable.run()), then it halts.
> 
> So, the PMD rule needs to be at least as good as JIT at determining if the variable can be hoisted.  This will prevent unintentional infinite loops at run time.  If the PMD rule is better than JIT, then that is just a bonus for the programmer.  I suspect the PMD rule can be better than JIT.  If I understand correctly, JIT is limited to looking at what is inlined due to runtime constraints.  PMD can has the time to go much deeper.  Also, if the loop calls Runnable.run(), then PMD can look at all classes that implement Runnable.  Yes, this will mean false negatives, but as long as it is better than JIT who cares.
> 
> If the PMD rule cannot be as good as JIT, then the PMD rule will catch most unintentional infinite loops and has a few false negatives for the nontrivial things.  This is much better than no PMD rule.  However, for those that use Graal, the PMD rule can be just as good as Graal since Graal produces a single executable (i.e. a closed system).
> 
> On Thu, Jul 22, 2021 at 7:38 AM Alex Otenko <[email protected] <mailto:[email protected]>> wrote:
> I think the problem is still the halting problem. You only have the text of the program, and you need to decide not only that quit=true exists, but that it is reachable from the loop body.
> 
> There are trivial cases where you can do this, but the world is full of nontrivial things. Say, createRandom...NP sets quit=true. Now what? Say, a subclass overrides createRandom...NP. Now what? Say, you call someone that has reference to this, and calls createRandom...NP. Now what? Is it the same instance or not?
> 
> Etc, etc, etc
> 
> The bottom line is: often there is no simple answer to a complex problem, and infinitely often there is no answer.
> 
> Alex 
> 
> 
> On Thu, 22 Jul 2021, 13:46 Nathan Reynolds via Concurrency-interest, <[email protected] <mailto:[email protected]>> wrote:
> It is not quite the halting problem.  The halting problem asks if the computation ends.  The PMD rule asks if among the many branches inside the loop's call tree if the exit variable is set.  It does not care if the branch is never taken.
> 
> Consider this code...
> 
> private boolean quit;
> 
> while (!quit)
> {
>    createRandomAlgorithmInPforNP();
> 
>    if (doesAlgorithmWork())
>    {
>       quit = true;
>    }  
> }
> 
> The method createRandomAlgorithmInPforNP() creates a random algorithm that runs in polynomial time and hopefully solves a NP problem.  The method doesAlgorithmWork() tests the created algorithm to see if it works.  This is an example of a halting problem.  We don't 100% know if an algorithm will ever be found and hence if the loop will run forever.
> 
> But, this does not matter for the PMD rule.  The PMD rule only cares that there is a "quit = true" in the loop body (or in the call tree).  Why?  The PMD rule is looking to see if "while (!quit)" can be hoisted out of the loop thus creating an infinite loop.  It will execute the same logic that JIT does to determine if "while (!quit)" can be hoisted.  We have working code (i.e. JIT) that we can use to implement the PMD rule.
> 
> On Thu, Jul 22, 2021 at 2:35 AM Andrew Haley via Concurrency-interest <[email protected] <mailto:[email protected]>> wrote:
> On 7/21/21 4:50 PM, Nathan Reynolds via Concurrency-interest wrote:
> 
> > 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.
> 
> I suspect that getting this right (no false positives or negatives) is
> equivalent to the halting problem, i.e. it's uncomputable. The best
> you can say is that if an expression used as the exit condition of a
> loop has a term hoisted from memory, the loop might not terminate.
> 
> However, while linting for that provides some information to the naive
> programmer, it "solves" the problem of infinite loops but ignores
> silently returning false results.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com <https://www.redhat.com/>>
> https://keybase.io/andrewhaley <https://keybase.io/andrewhaley>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> _______________________________________________
> 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] <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] <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

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