Re: Concurrency-interest Digest, Vol 196, Issue 11

Fuuuuuccccccckkkk offfffffff



> On Jul 19, 2021, at 12:02, [email protected] wrote:
> 
> Send Concurrency-interest mailing list submissions to
>    [email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
>    [email protected]
> 
> You can reach the person managing the list at
>    [email protected]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Are there real use cases with the Java access modes?
>      (Andrew Haley)
>   2. Re: Are there real use cases with the Java access modes?
>      (Viktor Klang)
>   3. Re: Are there real use cases with the Java access modes?
>      (Gregg Wonderly)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 19 Jul 2021 15:25:25 +0100
> From: Andrew Haley <[email protected]>
> To: [email protected]
> Subject: Re: [concurrency-interest] Are there real use cases with the
>    Java access modes?
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8
> 
>> On 7/19/21 3:06 PM, Gregg Wonderly via Concurrency-interest wrote:
>> 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.
> 
> That single optimization is no more than hoisting a memory load. It's
> one of the most common optimizations there is. It probably happens
> many times in every moderately complex method. It's not some kind of
> weird "let's turn this into an infinite loop" optimization.
> 
> For every non-volatile field load, in the absence of synchronization
> actions, it is entirely correct and proper to hoist the result of that
> load into a register, or propagate its value some other way. This is
> common in many programming language implementations, and is not going
> to change. It is a very important optimization.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 19 Jul 2021 17:14:50 +0200
> From: Viktor Klang <[email protected]>
> To: concurrency-interest <[email protected]>
> Subject: Re: [concurrency-interest] Are there real use cases with the
>    Java access modes?
> Message-ID:
>    <CANPzfU9JA-A38RnpwjDOgBsNhqOn=LfBCX3h4EPtxKZmo4LkFQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> In my experience,
> once developers are offered dedicated APIs for thread-safe communication
> and concurrency, many of the issues we're talking about here sort of
> disappear. After 12+ years of experience of both developing, maintaining,
> and observing users use things like Akka Actors, visibility/reording issues
> tend to be a non-problem—as the concurrency model itself handles the safe
> publication, and the access to state is never done in parallel.
> What remains is instead having to think about protocols—in the sense of
> communication patterns.
> 
> An application developer should, in my current view of the world, not ever
> have to deal with things such as Atomic*, s.m.Unsafe, volatile, etc.
> Not only because they are difficult to *prove that their use is 100%
> correct*, but also because they are completely, 100%, unrelated to writing
> application logic.
> 
> So ideally (IMO) such tools should be reserved for JDK & library writers,
> to be able to offer constructs to developers where they no longer need to
> worry about correctness-in-the-face-of-parallelism. It is also a situation
> where more experience and knowledge is to be expected of the developer-user.
> 
> Long rant, and I realize that everything above is a bit of a "yes that
> would be nice but it's not realistic".
> 
> And I second the opinion that even if "dangerous" optimizations would be
> turned off by default, if those optimizations would lead to significant
> performance benefits (they will), they'd become de-facto defaults,
> eseentially turning the entire exercise into a bit of a moot point.
> 
> On Mon, Jul 19, 2021 at 4:26 PM Andrew Haley via Concurrency-interest <
> [email protected]> wrote:
> 
>>> On 7/19/21 3:06 PM, Gregg Wonderly via Concurrency-interest wrote:
>>> 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.
>> 
>> That single optimization is no more than hoisting a memory load. It's
>> one of the most common optimizations there is. It probably happens
>> many times in every moderately complex method. It's not some kind of
>> weird "let's turn this into an infinite loop" optimization.
>> 
>> For every non-volatile field load, in the absence of synchronization
>> actions, it is entirely correct and proper to hoist the result of that
>> load into a register, or propagate its value some other way. This is
>> common in many programming language implementations, and is not going
>> to change. It is a very important optimization.
>> 
>> --
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> 
> 
> 
> -- 
> Cheers,
> √
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20210719/989f8ca3/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 19 Jul 2021 10:43:29 -0500
> From: Gregg Wonderly <[email protected]>
> To: Andrew Haley <[email protected]>
> Cc: [email protected]
> Subject: Re: [concurrency-interest] Are there real use cases with the
>    Java access modes?
> Message-ID: <[email protected]>
> Content-Type: text/plain;    charset=utf-8
> 
> 
> 
>> On Jul 19, 2021, at 9:25 AM, Andrew Haley via Concurrency-interest <[email protected]> wrote:
>> 
>> On 7/19/21 3:06 PM, Gregg Wonderly via Concurrency-interest wrote:
>>> 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.
>> 
>> That single optimization is no more than hoisting a memory load. It's
>> one of the most common optimizations there is. It probably happens
>> many times in every moderately complex method. It's not some kind of
>> weird "let's turn this into an infinite loop" optimization.
> 
> Because it's in logic control code, it becomes quite visible as “unknown” behavior that the explicit code elements don’t illustrate, in any way, as the desired behavior.  If volatile was the default, and the user had to instead declare non-volatile desires with @nonvolatile or some other declaration (no new keywords is a problem), then this optimization would be documented by the code structure and keyword/feature use.  I get that no-one really wants to be faced with this, yet, when the JMM was released, everyone was faced with it.
> 
>> For every non-volatile field load, in the absence of synchronization
>> actions, it is entirely correct and proper to hoist the result of that
>> load into a register, or propagate its value some other way. This is
>> common in many programming language implementations, and is not going
>> to change. It is a very important optimization.
> 
> There are countless data sharing APIs that suggest that non-volatile should never be something a user experiences, implicitly.  These APIs have to exist to “fix” problems with non-volatile being a default element of the language operations by explicitly controlling the moment that “volatile” data sharing occurs.  It’s an interesting history of concurrency design/development.   When java was released with just Vector and HashMap, we of course were all unexcited by the fact that there wasn’t ’non-volatile’ storage implementations that would make single user (thread) access fast and efficient.  Java “servers" suffered scaling pain from all kinds of things not “finished”.
> 
> Why would a user write conditional logic, intending that the control be with a non-volatile value?  A warning to the user on compilation would be the most helpful thing that could occur.  But we don’t have that to help people understand that their software logic is not being executed as expected.
> 
> I completely understand that this is now history, unfortunately.   But I still feel that this single thing about the Java language provides one of the most fragile elements of multi-threaded application behavior because it happens implicitly.
> 
> Gregg Wonderly
> 
>> 
>> -- 
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 
> ------------------------------
> 
> End of Concurrency-interest Digest, Vol 196, Issue 11
> *****************************************************

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