Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at