From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-15 21:07:03
> > And I feel that the interface (representing convenience,
> > flexibility, usability, etc.) is the first thing that a library will
> > 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
> most elegant designs if they result in code that isn't fast enough or
> efficient enough--especially in something like a multi-threading
> Peter Dimov's argument, if I understand correctly, is that the
> 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
> > 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
> > (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
[Batov, Vladimir] True. That falls into the same specialization
category. I simply do not want that specialization at the expense of the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk