I've thought a bit more about the various options that a vendor has with regards to sizeof mutex, condition, and shared_mutex (*), and this has indirectly made me realize why I feel uncomfortable with the native_handle accessor. It can't be used in portable code. At the same time, its presence puts pressure on you as an implementor to make std::mutex be a pthread_mutex_t (or a pointer to a pthread_mutex_t) since the OS is POSIX-compliant. This removes some of your implementation options; even if you don't find the underlying pthread_mutex_t particularly lean or well-performing, you'll be reluctant to replace it with an alternative. On Windows, some vendors will choose HANDLE and some - CRITICAL_SECTION* as the native handle, so it's not portable even across implementations on the same platform. In N2178, I've proposed pthread_mutex_t as part of the package, so while a "native handle" accessor would have the same disadvantage of tying std::mutex to pthread_mutex_t, it would've had the advantage of being portable. (*) mutex: 4, 8, 16, 44 condition: 4, 28, 32 shared_mutex: 4, 8, sizeof(pthread_rwlock_t), 104 are some of the options that come to mind, using the previously posted sizes as an arbitrary baseline.