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

Andrew, I appreciate all of the details you enumerate below about the design of Java and how concurrency with multi-threading is a primary design element.  The reference hoist has nothing to do with that though.  It has to do with optimizing the execution time of a block of code.  Yes, the analysis takes all the details of concurrent access into consideration around code paths of this thread, able to reach back into the class in some form.  But that analysis is totally based on the ‘volatile’ nature of the value, not simply on the fact that we are in a language that provides APIs that allow multi-threading to work.

I understand that the specifics seem integrated.  But my perspective is still that this reference hoist is assuming something that is so difficult to prove and variable based on what can be proved, that it’s an alarming side effect that is a surprise, more than it is a discernible behavior without extensive knowledge to all the implementation details which control when the hoist can actually occur.  Yes, that is what optimization is about, but the reality is that this optimization breaks the logic of the application and this is observable even in a debugger because of the logic change due to the hoisted read.  Other language compilers have over decades of development broken code due to mis-architected optimizations and we’ve not left them in.

The contention I am sensing revolves around the fact that this single optimization would appear to be something that everyone is relying on to solve lots of performance problems.  In days gone by of C and C++ programming, block-level, copy-of-value declarations were used as a moment to copy needed immutable references into block level values as a form of optimization of reference.  Things like

	SomeType val;
	if( ( val = externVal) != null ) {
		…lots of references to val...
	}

As a general non-locking mutation scheme, copy and replace (via CAS) reference strategies are ever present in concurrent systems, to avoid locks.  There’s just so many things that are done explicitly and provide such better documentation than a compiler optimization does.

The recurring counter point over the years, has been that experienced software developers can know why this occurs and will be able to readily fix the problem.  Really, believing that as a precursor to inaction, I feel, is a pretentious attitude that has caused a lot of people to not participate in many discussions.  It speaks to the belief that one can and does know everything, and that’s the only way to be a real software developer.  I’ve tried to have this discussion for years in a productive way.  But repeatedly, we arrive at “those are not real developers and so we don’t care about their problems” or “this is not a big problem, only some ignorant want-to-be programmers have this problem” so why should anyone care about them.

It’s really a privilege for all who spend time on this level of software construction and have the knowledge to understand all the details that are discussed in this group and amongst people of this caliber of knowledge.  Declaring it somehow required and achievable by all, is problematic, and that’s what I am continuing to stress.  Software doesn’t have to appear to be magic.  The notion of least surprise (https://en.wikipedia.org/wiki/Principle_of_least_astonishment <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>) is an old principle that has books written about it to try and illuminate the ideals of how we should consider system design for the users of those systems.

There are countless examples of how “training” is a requirement before performing lots of tasks in jobs and in life in general.  It’s not the training that I am complaining about.  It’s the notion that this single optimization is something that breaks software systems in non-predictable ways because it’s a large scale software system inspection, not a local, recognizable optimization that the user somehow knows they purposefully requested.  

I am go to once again cease here because I appear to be pushing buttons with my conversation mode and I am really not trying to make people made or defensive.  At some level these are hard discussions to have, I get that, but I just really sense to much defensive posturing and so I really don’t believe that the discussion can happen without creating even more walls to have to figure out how to talk through.

Gregg

> On Jul 20, 2021, at 5:41 AM, Andrew Dinn via Concurrency-interest <[email protected]> wrote:
> 
> On 19/07/2021 22:39, Gregg Wonderly via Concurrency-interest wrote:
>> Thanks for you comments.   I am still trying to assert that the problem is this kind of assumption about people writing the code, actually being trained software engineers.  Instead, think of them as self taught coders.  People who only every wrote “basic” or “vb” style integrations with just some knowledge that threads even exist, let alone, as in this case, knowing that the AWT event queue is involved and that there are threads (or more in the case of dialogs and other blocking actions) reaping events from the queue and dispatching them into your code.  Even the term callback or listener, for these people, doesn’t invoke any picture of “two” things working together.
> 
> And I am still trying to assert that we should not hobble the language implementation to cater for that category of 'programmer' (rabbit ears de rigeur). Java has been specified and implemented for use by skilled and knowledgeable professionals. That includes knowing about and having the skill to deal with the presence of multi-threading as a core element of the language, with all its attendant complexities.
> 
> Of course, as a Java implementor I make no assumption that all those who use Java will be skilled, knowledgeable professionals. What I do assume is that I don't have to take the concerns or failings of unskilled or ignorant 'would-be' coders into account.
> 
> By the way, I believe you are having your cake and eating it in the way you present your arguments here. You cited an example program as simple to understand and behaving as expected until you remove some logging code to simplify it and suddenly ... oh,. how surprising, a non-volatile access gets hoisted! At which point this simple to understand code becomes incomprehensible to the average reader.
> 
> In truth, if you know how to read the different versions of this code with an awareness that Java is a multi-threaded language the complexity is never absent. The surprise you describe is prima facie evidence that your posited average reader is not reading the code correctly, whether in the original or reduced version. They just think they understand it.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
> 
> _______________________________________________
> 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