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

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,
√

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