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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 08:46:45

Finally getting time to answering this:

David Abrahams wrote:

> 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.

The difference in the pthreads case is a difference in the data that
must be stored in the Boost.Threads mutex object: each one needs to
store both a mutex and a condition variable, though I suppose--at the
expense of requiring the storage to be dynamically allocated--space for
the condition variable could be allocated only on platforms that don't
support pthreads_timedlock.

In the Win32 cases, if you're going to use timed mutex functions (or, on
Win9x, try mutex functions), the Boost.Threads mutex object needs to
allocate a Win32 mutex object; if not, it can allocate a Win32 critical
section. Currently Boost.Threads mutexes objects can tell whether you
intend to use try or timed functions by whether you declare a try_mutex
or timed_mutex, and allocate the appropriate Win32 synchronization
object accordingly. But if all mutex types are combined into one there
won't be any way for it to tell, and it will have to allocate a Win32
mutex object always.

Another option in the Win32 case, which Peter already mentioned, is to
write an alternate implementation of critical sections (such as the one
Alexander Terekhov outlined an implementation for) that supports
both try and timed functions. If done well, this would be desirable even
if the mutex types are not combined.

Mike