Re: [boost] [lockfree] review

Subject: Re: [boost] [lockfree] review
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-26 12:55:12

on Wed Aug 24 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:

> Dave Abrahams wrote:
> [...]
>> >   mi.lock();
>> >   i = 1;
>> >   mi.unlock();
>> >
>> >   mj.lock();
>> >   j = 2;
>> >   mj.unlock();
>> >
>> > can be transformed to
>> >
>> >   multi_lock(mi, mj); // deadlock free
>> >   j = 2;
>> >   i = 1;
>> >   mi.unlock();
>> >   mj.unlock();
>> >
>> > and thus result in reodering i = 1 and j = 2.
>> >
>> > With C++11 default atomics (SC) for i and j such reodering is
>> > prohibited.
>> 
>> As it is with C++11 mutexes, IIUC.  
>
> Mutexes need only *acquire-release* semantics coupled with RMW(s) to
> result in *SC* for associated race-free data, as observed by another
> thread(s).

I think I know that...

>
> C++11 default atomics are *SC* without mutexes (lockfree and all that
> stuff)... *SC* is more expansive than *acquire-release* in terms of
> sync

...and I think I know that...

> 
> on platforms such as:
>
>> If you have contrary evidence, please point to it.
>
> http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
> (PowerPC)
>
> I mean:
>
>   Load SC: hwsync; ld; cmp; bc; isync
>   Store SC: hwsync; st
>
> alternative mappings:
>
>   Load SC:  ld; hwsync
>   Store SC: lwsync; st; hwsync
>
> Note that *acquire-release* does NOT need *hw*sync:
>
>   Load Acquire: ld; cmp; bc; isync
>   Store Release: lwsync; st

I'm pretty sure I did't know that part, but I don't yet see what it has
to do with your assertion.

IIUC, using mutexes in the implementation of C++0x atomics has always
been considered an available choice for implementors.  If that
reordering were allowed for mutexes, wouldn't that weaken the semantics
of atomics?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com