[concurrency-interest] Single writer multiple readers no barriers -- safe ?

Vitaly Davidovich vitalyd at gmail.com
Fri Nov 29 19:01:57 EST 2013


Right, for archs where volatile loads actually have a cost (I.e. not just a
compiler barrier but also hardware level order enforcement), it may be
prudent to only issue a compiler barrier load at certain strategic points
(if such control is available).  It's not really cache coherence that's the
issue (coherence is always there even for plain load/store) but rather
effects on out of order execution/pipelining that the volatile load may
cause.

Sent from my phone
On Nov 29, 2013 6:49 PM, "Aaron Grunthal" <aaron.grunthal at infinite-source.de>
wrote:

> On 30.11.2013 00:13, Vitaly Davidovich wrote:
>
>> If the field is volatile but accessed through unsafe direct member
>> access, I'm not sure whether the access is treated as volatile or not in
>> that case.  However, I don't see the point in marking the field as
>> volatile and accessing through unsafe and expecting compiler barrier -
>> this is what AtomicReference.get() will achieve.
>>
>
> I've tried that a while ago and it looked like that a plain Unsafe read to
> a volatile field (or a normal field for that matter) will not get
> loop-hoisted. So it seems to sort-of act like a compiler barrier. Whether
> that's intentional behavior or just an implementation detail was never
> figured out.
>
> Although it might be useful for concurrent data structures on non-x86
> platforms to optimistically attempt a stale read to avoid cache-coherency
> costs. I think I've seen a few places the j.u.c Classes where that's done.
> If the compiler were free to reorder through the plain unsafe reads it
> might yield more optimal assembly output.
>
>
> But you always have the reverse option of accessing a normal field through
> unsafe, which gives you a barrier-free reads if needed and all the other
> ordering options as needed. But that's something for fine-tuned algorithms
> where every single instruction counts and not for Thomas' example.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131129/cc206474/attachment.html>


More information about the Concurrency-interest mailing list