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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-12 17:09:17

Mike,

IMHO your comments below justifying different mutex types make sense.
However, I feel that you look at the problem from the *implementor*
point of view that is drastically different from the view of the library
*user*. And I feel that the interface (representing convenience,
flexibility, usability, etc.) is the first thing that a library will be
judged by. I feel that for the user having different types of mutexes is
inconvenient and unnecessary restricting. It is because when I create a
mutex, I identify a resource that I want to serialize access to (it's a
strategic decision in military terms :-) ). However, *how* I serialize
the access (via blocking lock or try/timed locks) is not generally known
at the time and will be defined on the case-by-case basis (when I'll be
actually creating appropriate locks -- it's a tactical decision). A
typical and very basic application I am working on discriminates two
threads (and, therefore the appropriate mutex) -- the first always
applies a blocking lock (scoped_lock) and the other thread only steps in
through the successful try-lock. 

Having additional (and maybe unused) data in a mutex does not seem like
a huge problem (as long as it does not impose performance penalties) --
memory is cheap and mutexes are not usually created in huge numbers.
More so, I believe in boost there are techniques/classes minimizing
waste.

Best,
V.

> > Now that we got rid of the excess locks, how about doing the same
with
> the
> > mutexes?
> 
> 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?