From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 08:45:04
Finally getting time to answering this:
Batov, Vladimir wrote:
> 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
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
> More so, I believe in boost there are techniques/classes minimizing
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk