[boost] Re: Boost.Threads: Do we need all those mutexes?

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-12 09:48:16

Michael Glassford <glassfordm_at_[hidden]> writes:

> I had considered this, but there does seem to be some benefit in
> having separate mutex types, which is what I assume led to there being
> three mutex types and three lock types in the original design. You've
> noted these reasons below, but I'll reiterate:
>
> * On pthreads, the timed mutex requires an additional data member,
>   (condition variable) to handle cases when pthreads_timedlock isn't
>   supported.
>
> * On WinNT, the timed mutex operations require a win32 mutex object,
>   while the mutex and try mutex can use a win32 critical section.
>
> * On Win9x, the timed mutex and try mutex operations require a win32
>   mutex object, while the mutex can use a win32 critical section.
>
> In other words, on the most widely-used platforms, collapsing the
> mutex types into one imposes some penalty (larger mutex object or more
> limited implementation options) on users. Also (I ask, not as a
> hypothetical question, but as a request for information): is there
> another platform where combining the mutex types incurs a similar or
> worse penalty?

If the difference is in the code that must be generated within the
locking function, I'd guess that the differently-named functions can
handle it.  If the difference is in the data stored in the mutex
and/or the lock, it could be an issue.  You might be able to use
boost::variant to minimize storage.  It would be worth doing some
experimentation to see whether optimizers can make the other
overheads disappear.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com