This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] mutex vs. cstdatomic
- From: "Chris Fairles" <chris dot fairles at gmail dot com>
- To: "Paolo Carlini" <paolo dot carlini at oracle dot com>
- Cc: "Benjamin Kosnik" <bkoz at redhat dot com>, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, "Jack Howarth" <howarth at bromo dot med dot uc dot edu>
- Date: Sat, 13 Dec 2008 06:17:52 -0500
- Subject: Re: [v3] mutex vs. cstdatomic
- References: <20081212232738.0db851ec@balbo.artheist.org> <49437736.4000906@oracle.com>
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.
Chris