From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-15 07:37:25
Howard Hinnant wrote:
> If pthread semantics can be implemented more efficiently using atomics
> (which C++0X will have), then that's great. There is no requirement
> that pthread_cond_t be at the center of std::condition_variable.
Thanks for the clarification. You might like to adjust the
documentation to say that the implementation is expected to be no
slower than any native mutex / condition variable.
> On the other hand, this is an OS-level functionality. If the semantics
> of pthread_cond_t can be implemented more efficiently on some platform
> than is currently done, I imagine that the OS vendor will likely do
> it, and call it pthread_cond_t.
The semantics of pthread_mutex&cond_t are more complex than are needed
for std::mutex&cond_var. Slightly more efficient pthread functions
could be implemented by inlining (maybe some implementations already do
this). But the overhead of using a single type for all kinds of mutex
(recursive, non-recursive, checking etc), with run-time look up of the
kind, is unavoidable. Since the optimal uncontended mutex locking code
is just two inline instructions, even adding one additional 'if
kind==x' will measurably reduce performance.
>> Apart from performance, another problem with wrapping existing
>> functionality is that the lowest common denominator of all the
>> constraints from the existing implementations has to be passed on to
>> the user. For example, in the condition variable code that I
>> posted, a mutex is locked from one thread and then unlocked from another. I
>> think this works for all of the mutexes that I've written (spinlock,
>> loop-calling-yield, futex) (though I may be missing something - I'm
>> not an expert in any of this). Because it works with futex, I guess that
>> the Linux pthread_mutex may also work in DEFAULT mode, though it's
>> possible that there is something in glibc that breaks it. However,
>> POSIX says that "if a thread attempts to unlock a mutex that it has
>> not locked ... undefined behavior results." So the wording in N2447 also
>> requires that "the current thread of execution shall own the mutex"
>> before it can call unlock().
> The Posix committee has considerable experience and expertise in this
> area. While I do not trust their advice blindly, I also do not
> dismiss it lightly (quite the contrary). Transferring mutex ownership
> among threads is not one of the decisions they have made that I've
> questioned. I've lacked the motivation. If you have strong
> motivation for relaxing this restriction, coupled with some insight
> into the posix decision and why it should be relaxed, I am most
You are not the only one to have argued in this thread that the
status-quo has been arrived at as a result of much deliberation by
experts whose conclusions we should trust. While I don't exactly
disagree with that attitude, I suggest that the level of deference
might perhaps be dropped back one notch.
The rationale section in the pthread_mutex documentation says nothing
about the restriction on locking in one thread and unlocking in
another. Maybe some readers can propose an explanation? My guess is
that someone, long ago, decided to prohibit behaviour that they
couldn't think of a use for, and that this has simply been carried forward.
My motivation for relaxation is simply that it's useful (essential?) in
the algorithm that I presented for a condition variable. (I'm curious
to know if anyone has spotted any fundamental problems with that
algorithm, by the way.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk