This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
std::mutex
?Section: 33.6.4.2.2 [thread.mutex.class] Status: Resolved Submitter: Peter Dimov Opened: 2008-04-18 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [thread.mutex.class].
View all issues with Resolved status.
Discussion:
[Note: I'm assuming here that [basic.start.init]/1 will be fixed.]
Currently std::mutex
doesn't support static initialization. This is a
regression with respect to pthread_mutex_t
, which does. I believe that
we should strive to eliminate such regressions in expressive power where
possible, both to ease migration and to not provide incentives to (or
force) people to forego the C++ primitives in favor of pthreads.
[ Sophia Antipolis: ]
We believe this is implementable on POSIX, because the initializer-list feature and the constexpr feature make this work. Double-check core language about static initialization for this case. Ask core for a core issue about order of destruction of statically-initialized objects wrt. dynamically-initialized objects (should come afterwards). Check non-POSIX systems for implementability.
If ubiquitous implementability cannot be assured, plan B is to introduce another constructor, make this constexpr, which is conditionally-supported. To avoid ambiguities, this new constructor needs to have an additional parameter.
[ Post Summit: ]
Jens: constant initialization seems to be ok core-language wise
Consensus: Defer to threading experts, in particular a Microsoft platform expert.
Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams, Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker, Peter Dimov to alert them of this issue.
Lawrence: What about header file shared with C? The initialization syntax is different in C and C++.
Recommend Keep in Review
[ Batavia (2009-05): ]
Keep in Review status pending feedback from members of the Concurrency subgroup.
[ See related comments from Alisdair and Daniel in 827(i). ]
[ 2009-10 Santa Cruz: ]
NAD EditorialResolved. Addressed by N2994.
Proposed resolution:
Change 33.6.4.2.2 [thread.mutex.class]:
class mutex { public: constexpr mutex(); ...