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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-15 21:07:03

Mike,

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

[Batov, Vladimir] I never advocated forgetting efficiency. Only that the
first thing needs to be addressed/settled on first. Then, we move on to
the second within the constraints of the first choice.

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

[Batov, Vladimir] It is restricting because I presume that different
types of mutexes will have different functionality. Therefore, the plain
mutex will not have something I need for try_lock. If that assumption of
mine is not correct and, say, try_mutex is complimentary -- an efficient
implementation of the generic mutex (with efficiency vs. functionality
trade-offs), then I am fine with it. 

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

[Batov, Vladimir] True. I am fine if we address the mainstream use first
(that is, a generic mutex represents an access serialization to the
relevant data with the *kind* of serialization (timed, try, etc.)
refined by locks). Then, mutex refinements will be just that --
refinements for a particular purpose. Like generic mem. allocation
mechanism (kinda OK for everyone) vs. optimized (extremely good for
some).

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

[Batov, Vladimir] True. That falls into the same specialization
category. I simply do not want that specialization at the expense of the
mainstream users/applications.