[v3] mutex vs. cstdatomic

Chris Fairles chris.fairles@gmail.com
Sat Dec 13 13:46:00 GMT 2008

On Sat, Dec 13, 2008 at 3:49 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>> There appears to be an include ordering issue on darwin:
>> No joy:
>> #include "gstdint.h"
>> #include <cstdatomic>
>> #include <mutex>
>> OK:
>> #include "gstdint.h"
>> #include <mutex>
>> #include <cstdatomic>
>> Adjusting this allows bootstrap on darwin again.
> Most likely I'm saying the obvious, but certainly the above should be
> further investigated: if the facilities in <cstdatomic> explicitly
> require the facilities in <mutex>, then the latter should be included
> explicitely by the former, otherwise, if it's because of an
> implementation detail, that is <mutex> includes something that
> <cstdatomic> also happen to need and at the moment doesn't include by
> mistake, that should be also fixed ASAP.
> Paolo.

Keep note that <mutex>'s unique_lock<> should be using atomic_bool for
its internal _M_owns variable so <mutex> will eventually need to
include <cstdatomic> (trying to come up with a patch atm but
cstdatomic isnt playing nice).

With a straight up swap of bool for atomic_bool, I'm seeing a lot of these:

atomic_2.h:312: _ITp
std::__atomic2::__atomic_base<_IntTp>::load(std::memory_order) const
volatile [with _ITp = bool]:
 Assertion `__m == memory_order_release' failed.


More information about the Gcc-patches mailing list