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

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

Finally getting time to answering this:

Batov, Vladimir wrote:

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

Actually, I was trying to look at it from the point of view of the 
original designer of the library.

>  And I feel that the interface (representing convenience,
> flexibility, usability, etc.) is the first thing that a library will be
> judged by. 

Perhaps, but the next thing it will be judged by is efficiency and 
speed. Ultimately, many C++ programmers won't use even the cleanest and 
most elegant designs if they result in code that isn't fast enough or 
efficient enough--especially in something like a multi-threading library.

Peter Dimov's argument, if I understand correctly, is that the "cleaner" 
design could be made as fast/efficient as the current one, not that we 
should choose a cleaner design at the expense of speed or efficiency.

 > I feel that for the user having different types of mutexes is
> inconvenient and unnecessary restricting. 

Inconvenient I can see, but how is having more choices 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 

Not for you, perhaps, but I can guarantee that there are others who 
don't feel that way.

 > (as long as it does not impose performance penalties) --s
> memory is cheap and mutexes are not usually created in huge numbers.

Memory isn't cheap for everybody: there are still some (many?) who are 
forced to work in more constrained environments. For instance, 
programmer's of handheld devices often deal with insufficient memory 
problems.

 > More so, I believe in boost there are techniques/classes minimizing
 > waste.

Mike