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

I am specifically against the single optimization I illustrated that rewrites code to be non-logically executed, without the user being aware of this happening and not being warned that an optimization has potentially made the logic of the application not work as expected.

But, overall, least surprise is the real detail.  The non-volatile behavior, of data sharing not working, is fine, because that’s already documented.  You can search about all kinds of things to find the data sharing conversations.  But this single optimization is a problem that doesn’t need to happen behind the users back.  If you are trying to optimize a loop to avoid a memory reference in a loop that you know is controlled by a non-volatile reference that you know is not mutated by some other thread, then you can write that code explicitly, and all is good, because the logic that one reads in the source, is the logic that the JVM executes for you.   When you run a debugger, or review the code logic, it’s entirely clear what is happening.

Gregg Wonderly

> On Jul 19, 2021, at 4:26 AM, Andrew Dinn <[email protected]> wrote:
> 
> On 18/07/2021 05:13, Gregg Wonderly via Concurrency-interest wrote:
>> You still assume that everyone trying to use a Java is a well educated, trained and knowledgeable software engineer.  That’s just not the reality that exists.
> So, essentially, your argument is that we should significantly damage the performance of Java in order to make a relatively common example of ignorantly and badly written multi-threaded code (but not all such code) work correctly because that will allow people who don't know how to write multi-threaded code correctly to continue to produce more of it?
> 
> I believe you are fixing the wrong problem here.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

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