[concurrency-interest] AtomicXXX.lazySet and happens-before reasoning

Vitaly Davidovich vitalyd at gmail.com
Sat Oct 8 13:11:29 EDT 2011


+ rest of the group

On Sat, Oct 8, 2011 at 1:10 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi Hans,
>
> I was under the impression that lazySet is purely a StoreStore barrier, and
> only specifies that the lazySet cannot be reordered with prior writes -- I
> never saw mention of requiring no reordering with prior loads.  Here's
> Doug's evaluation:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6275329, where only a
> store-store is mentioned.  If it's really a LoadStore | StoreStore, good to
> know ...
>
> Thanks
>
> On Sat, Oct 8, 2011 at 12:06 AM, Boehm, Hans <hans.boehm at hp.com> wrote:
>
>>  LazySet() needs to prevent reordering of ordinary memory operations with
>> a subsequent lazySet() operation.  In the JSR 133 Cookbook style, that can
>> be implemented with a LoadStore | StoreStore fence preceding the lazySet()
>> call.  So yes, that makes sense.****
>>
>> ** **
>>
>> Real machines tend to require neither of those fences (x86) or combine
>> them into a single instruction.****
>>
>> ** **
>>
>> Hans****
>>
>> ** **
>>
>> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
>> *Sent:* Friday, October 07, 2011 5:10 PM
>> *To:* Boehm, Hans
>> *Cc:* concurrency-interest at cs.oswego.edu; Ruslan Cheremin
>>
>> *Subject:* Re: [concurrency-interest] AtomicXXX.lazySet and
>> happens-before reasoning****
>>
>>  ** **
>>
>> Does it even make sense to say that lazySet needs a LoadStore fence? The
>> get() does but that's because it has same semantics as volatile read. ***
>> *
>>
>> On Oct 7, 2011 7:29 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:****
>>
>> > From: Ruslan Cheremin [mailto:cheremin at gmail.com]
>> > > It also needs a LoadStore fence, in both cases.
>> >
>> > But why lazySet needs LoadStore fence? It seems what lazySet javadoc
>> > does not put any ordering constraints on loads...
>> I do read it as imposing such a constraint, though we all agree that a
>> more precise spec would help.  Certainly C++11's memory_order_release
>> imposes such a constraint.
>>
>> If not, it would mean that e.g.
>>
>> Thread 1:
>> x = ...;
>> ...
>> r1 = x;
>> done_with_x.lazySet(true);
>>
>> Thread 2:
>> if (done_with_x.get()) {
>>   x = ...;
>>   ...
>>   r2 = x;
>> }
>>
>> wouldn't work as expected.
>>
>> In my opinion, that's an indefensible design point, especially since I
>> don't believe it makes lazySet appreciably cheaper on any modern
>> architectures.
>>
>>
>> >
>> > > In particular, if v is volatile (and certainly if it's accessed using
>> > lazySet), and x and y are ordinary variables,
>> > > then the assignments to x and y in the following may be visibly
>> > reordered:
>> > > x = 1;
>> > > v = 2;
>> > > y = 3;
>> >
>> > You mean what vstore is not "transparent" upside down, but
>> > "transparent" downside up, so this
>> >
>> > y=3
>> > x=1
>> > v=2
>> >
>> > is allowed reordering?
>> Correct.
>>
>> Hans
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest****
>>
>
>
>
> --
> Vitaly
> 617-548-7007 (mobile)
>



-- 
Vitaly
617-548-7007 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111008/9d83a775/attachment.html>


More information about the Concurrency-interest mailing list