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.

### 828. Static initialization for `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. ]

[ 2009-10 Santa Cruz: ]

> NAD Editorial Resolved. Addressed by N2994.

Proposed resolution:

Change 33.6.4.2.2 [thread.mutex.class]:

>     class mutex {
>     public:
>       constexpr mutex();
>       ...