RFR 8151198: VarHandle factory-specific exceptions
hboehm at google.com
Sat Apr 9 16:17:24 UTC 2016
Compiler fence with respect to all other memory accesses? Opaque and
It sounds like, unlike volatile, this doesn't support the equivalent of
synchronization elimination. An opaque access to a thread private location
still has visible effects beyond an ordinary access?
We've established that it implies single-copy atomicity. What about cache
On Sat, Apr 9, 2016 at 7:15 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> The issue with "program order" is it may confuse people, particularly ones
> that don't know what a compiler fence is, into thinking it implies CPU
> fences as well (they may not know those either, perhaps). You'd need to
> define program order anyway for them. IMHO, I'd rather see compiler fence
> used in description rather some more general notion; most people using this
> API will understand compiler fence, no need to make it more abstract.
> On Saturday, April 9, 2016, Doug Lea <dl at cs.oswego.edu> wrote:
> > On 04/09/2016 09:03 AM, Vitaly Davidovich wrote:
> >> Just to confirm - opaque is also a compiler fence right? C++ relaxed
> >> doesn't
> >> require compiler fence, but it sounds like opaque does. Would be good
> >> clarify this, unless "program order" is the way you want to do that.
> > "Program order" normally requires a compiler fence.
> > Most people don't know what a compiler fence is though, and
> > it is not especially easy to define. So I don't think this would
> > help.
> > -Doug
> > On Saturday, April 9, 2016, Doug Lea <dl at cs.oswego.edu
> >> <mailto:dl at cs.oswego.edu>> wrote:
> >> On 04/08/2016 02:39 PM, Hans Boehm wrote:
> >> My prior impression was that Opaque was intended to be similar
> >> a C++
> >> memory_order_relaxed access to a variable that is declared as
> >> both atomic
> >> and volatile, with the unordered interpretation of C++
> >> Yes. This is awkward to spell out in detail, but surely there is
> >> some way to say it that is more illuminating than confusing.
> >> Especially since the implementation on all known processors
> >> is straightforward -- reading/writing (all bits atomically) in
> >> program order.
> >> -Doug
> >> --
> >> Sent from my phone
> Sent from my phone
More information about the core-libs-dev