Re: Java Memory Model and ParallelStream

On Fri, Mar 6, 2020 at 5:26 AM Doug Lea via Concurrency-interest <
[email protected]> wrote:

> In other words, java.util.concurrent components make strong enough
> guarantees that almost nobody ever needs to think about them. On the
> other hand, they so often invisibly do what people expect that is too
> easy for some to imagine other nonexistent rules are responsible.
>

Yes, I have significantly benefited from java.util.concurrent over many
years, and I'm grateful for your work on it. I use these classes in almost
every program I ever write, and have done for many years. Usually I use
concurrent collections along with futures for imposing a partial ordering
where needed, but sometimes I have to get down to a lower level and
implement custom locking schemes with semaphores and mutexes, etc. -- and
semaphores and mutexes already get to the level of "this is hard enough to
get right that there's a good reason for higher-level concurrency
abstractions".

However I also know there was a lot of very careful and principled work
that went into the implementation of java.util.concurrent, and I have run
into a situation a few times where deferring to any sort of high-level
abstractions just wasn't enough, sometimes because I was running into
performance issues. The code example I gave does not use
java.util.concurrent, because it doesn't need those classes. I just wanted
to know if this pattern is safe. My logical mind said: Of course, logically
how could this not be safe? -- but I have seen enough warnings about
non-volatility of Java array elements that I thought I should check with
the experts.

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