828. Static initialization for std::mutex?

Section: 33.4.3.2.1 [thread.mutex.class] Status: Resolved Submitter: Peter Dimov Opened: 2008-04-18 Last modified: 2016-02-10

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 EditorialResolved. Addressed by N2994.

Proposed resolution:

Change 33.4.3.2.1 [thread.mutex.class]:

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