Howard Hinnant wrote:
Andrey Semashev wrote:
Beman Dawes wrote:
I'm not totally enthralled by the condition_variable_any name. If someone has a suggestion for a more meaningful name, now is a good time to speak up.
cond_var would better for my carpal tunnels.... I was also happy with 'condition'. (Very long names should perhap be reserved for bad things. The time that it takes me to type reinterpret_cast is normally long enough to make me reconsider whether it's appropriate!)
I wonder why not making condition_variable a template with a mutex type in its template parameter. We could specialize it on the boost::mutex type to have the current optimized condition_variable implementation and leave it implemented as condition_variable_any for a general case.
The rationale for the current design (with different names) can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#condition...
Thanks for the link. Quote: "For those platforms which offer a native condition variable (e.g. pthread_cond_t), C++ should offer as thin a wrapper as possible around that OS functionality." I think this is a mistake. What is the motivation? Portability, perhaps? By wrapping the existing functionality, we bound the performance that we can achieve: we'll never be faster than C code. High-performance concurrency primitives will be crucial to getting the most from the next generations of multi-core hardware. We should at least be considering building from the most basic building blocks available. (Consider the shared_ptr implementation, for example, which only falls back to pthread_mutex if it doesn't have a better solution using atomics.) My experience with pthread_mutex is that it's simple to write significantly faster (but less-portable) mutexes, and I think that Boost should be taking that approach, with the wrapped OS functionality offered only as a fallback. I have not yet tried to benchmark pthread_cond, but I would be surprised to find it faster than the condition variable using mutexes that I posted elsewhere in this thread [though that code may well have some horrible flaw in it.....]. 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(). Regards, Phil.