Hi Doug, I somehow missed your reply and just now noticed it after Martin's last email quoted it -- thanks for elaborating.
The new name is required because opaque is only "like" C++ > memory_order_relaxed. > See the jmm-dev list discussions last year for details, but annoyingly, > Java normal variables and C++ memory_order_relaxed are not quite the > same, and neither are the same as C-volatile/opaque. AFAICT, difference between java normal load/store and memory_order_relaxed is the latter guaranteeing atomicity. If I'm understanding you correctly, "opaque" is *just* compiler barrier and does not guarantee atomicity? If that's so, what is/are the use case(s) for opaque? Andrew mentioned preventing roach motel movement of loads/stores into the motel. Is there something more than that? Assuming my above statement is correct, it would seem like having memory_order_relaxed would be more useful than simply "no code motion around this load/store", or if not more useful, just useful on its own; there's plenty of code that doesn't care about ordering but would not tolerate torn reads/stores. On Fri, Jan 22, 2016 at 8:23 AM, Doug Lea <d...@cs.oswego.edu> wrote: > On 01/22/2016 04:51 AM, Andrew Haley wrote: > >> On 22/01/16 00:01, Vitaly Davidovich wrote: >> >>> I think the get/setOpaque methods need a bit more explanation ("opaque" >>> is >>> an odd naming choice, IMO). Specifically, it says the operations are >>> done >>> in program order but have no effect on inter-thread ordering/visibility. >>> Is this spec verbiage for a full compiler-only fence? >>> >> > > Basically yes. It would be the same as C "volatile" (not C++/C11 > "atomic"), if C volatile had a memory model spec. But in any case > we can't use "volatile" for this in Java because it already means > something else. > > >> It's like C++ memory_order_relaxed, I guessed. I understand that but >> not "opaque". >> >> > The new name is required because opaque is only "like" C++ > memory_order_relaxed. > See the jmm-dev list discussions last year for details, but annoyingly, > Java normal variables and C++ memory_order_relaxed are not quite the > same, and neither are the same as C-volatile/opaque. > > -Doug > > > >