[concurrency-interest] Atomic.*lazyGet

Doug Lea dl at cs.oswego.edu
Wed Aug 8 09:57:54 EDT 2012

On 08/08/12 09:32, Vitaly Davidovich wrote:
> Doug, so what was the overwhelming reason for scrapping the Fences API? Is it
> because the JMM would need a revision, as you mentioned? I'd think if Fences was
> some "advanced" API with a caveat emptor that you need to know what you're doing
> then it would be OK - or is that a can of worms you'd rather not open?

I think this proposal died for three reasons:

* The argument that the API is prone to misuse, even by experts.
There are some highly non-intuitive cases; for example those
involving accessing array elements.

* The fact that there are some minor errors in the JMM/JLS specs
that don't matter much for most purposes, but do for the otherwise
reasonable semi-formal additions in the Fences API. So this
should be done with at least a minor JMM revision. But no one
wants to do a minor revision when there are also some known
major problems that need attention. None of these major
problems are very interesting to java programmers, but they
do include for example erroneous claims that some compiler
optimizations are illegal, that compile writers happily ignore.
These problems cannot be addressed with just a few pointwise fixes.

* The notion that it would be better to instead overhaul
this part of the JMM to be more in line with the C++11 memory model specs,
focusing on explicit modes rather than fences. But no one has come
up with a way to do so. C++ could get away with the notion that
any program with races has undefined behavior. Java must define
behaviors that make minimal safety/security guarantees.
It is very challenging.


More information about the Concurrency-interest mailing list