Proposed resolution:

Change [thread.mutex.class]:

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

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2994.

[ See related comments from Alisdair and Daniel in 827. ]

[ Batavia (2009-05): ]

Keep in Review status pending feedback from members of the Concurrency subgroup.

[ 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

[ 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.

[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.