This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [v3] mutex vs. cstdatomic

From: "Peter Dimov" <pdimov at mmltd dot net>
To: "Chris Fairles" <chris dot fairles at gmail dot com>, "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 19:57:57 +0200
Subject: Re: [v3] mutex vs. cstdatomic
References: <20081212232738.0db851ec@balbo.artheist.org> <49437736.4000906@oracle.com> <fac6bb500812130317k474f66f5w1364799b9873f673@mail.gmail.com>

Chris Fairles:

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>

I'm not sure. The only reason you'd want an atomic_bool for _M_owns is to make unique_lock tolerate data races. But it makes little sense to access an unique_lock from a thread which did not create it since only the thread that locked the mutex can unlock it.

References:
- [v3] mutex vs. cstdatomic
  - From: Benjamin Kosnik
- Re: [v3] mutex vs. cstdatomic
  - From: Paolo Carlini
- Re: [v3] mutex vs. cstdatomic
  - From: Chris Fairles

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]