From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-08-22 10:31:46
On Aug 22, 2007, at 10:11 AM, David Abrahams wrote:
> on Mon Aug 20 2007, Howard Hinnant <howard.hinnant-AT-gmail.com>
>> Here is a link to a reference implementation and a FAQ for mutexes,
>> locks and condition variables I am currently anticipating proposing
>> for C++ standardization (or subsequent TR).
> "However if the external mutex is (or is layout compatible with) a
> pthread_mutex_t, then there is no need for the internal
> pthread_mutex_t. When one wants to wait, one simply waits on the
> external pthread_mutex_t with the internal pthread_cond_t."
> This smells a little fishy. It seems to imply that pthreads can wait
> on any old data type that happens to be layout-compatible with
> pthread_mutex_t. Is that really true?
Perhaps the wording isn't precise enough.
The intent is that on pthreads:
When condition<mutex>::wait is called with a lock whose mutex_type is
std::mutex (e.g. unique_lock<mutex>), then there is no need for an
internal pthread_mutex_t in condition<mutex>. Internally the wait
function can simply:
where lock.mutex()->native_handle() is returning a pointer to the
member mut_ of the std::mutex referenced by the passed in lock.
Imho this is a critical optimization. It isn't that it makes the wait
faster (it does, but who cares, it blocks anyway). It is that it
makes the std::condition<std::mutex> smaller in size. Since
condition<mutex> is anticipated to be a low level, foundation tool,
possibly used in many places, its size becomes important just for
reducing L1 cache misses (for the exact same reason that people care
that sizeof(vector<int>) is 3 words, not 4 words).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk