From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 21:10:01
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.