Re: MT Design Question
On 2010-08-25 20:49, Scott Meyers wrote:
Chris M. Thomasson wrote:
Humm... Not exactly sure what your getting at here. I know that an
eventcount allows one to skip a mutex around the "predicate".
Can you summarize what an eventcount is and the conditions under which
one would use it? I'm not familiar with the idea, and googling around
doesn't give me a clear notion. All the people who discuss it seem to
already know what it is :-)
Still not sure what you are getting at. Can you show me a simple
example of how the no-op mutex can be used?
Traditionally, a condvar is used to let a thread sleep until some shared
state is ready to be examined or modified. When the condvar is notified,
the thread is awakened and given the mutex for the shared state. In my
case, what I want is to have a thread spawn several search tasks, then
sleep until one of them is done. When it's awakened, there is no shared
state to examine (because each search task will return a separate
future, and the state referred to by each future is internally
synchronized), so there is no need for a mutex.
Part of the mutex being there is to prevent notification races (without
it, you might loose a notification). You do have shared data as well,
your notification flag (or whatever you are using).
All things being equal, condition_variable_any should have more overhead
than condition_variable. If you look at Boost threads
condition_variable_any simply uses an additional internal mutex to do
what you would do with the standard condition_variable usage pattern by
hand.
E.g. (from Boost boost/thread/pthread/condition_variable.hpp):
class condition_variable_any
{
[...]
template<typename lock_type>
void wait(lock_type& m)
{
int res=0;
{
detail::interruption_checker check_for_interruption(&cond);
{
boost::pthread::pthread_mutex_scoped_lock
internal_lock(&internal_mutex);
m.unlock();
res=pthread_cond_wait(&cond,&internal_mutex);
}
m.lock();
}
if(res)
{
boost::throw_exception(condition_error());
}
}
[...]
But the condvar API
requires a mutex, so the idea is that passing a no-op mutex would avoid
the cost of acquiring a mutex that the API requires but that isn't
needed in this scenario.
>
> A similar scenario is discussed in the thread I referred to earlier:
> http://tinyurl.com/22mvpso .
Not really true. For condition_variable_any, you can get away with that,
since it already uses an additional internal mutex. For
condition_variable you need to use a valid mutex, not just some dummy.