Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-14 17:14:29

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:

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at