RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
Now that we got rid of the excess locks, how about doing the same with the mutexes?
I had considered this, but there does seem to be some benefit in having separate mutex types, which is what I assume led to there being three mutex types and three lock types in the original design. You've noted these reasons below, but I'll reiterate:
* On pthreads, the timed mutex requires an additional data member, (condition variable) to handle cases when pthreads_timedlock isn't supported.
* On WinNT, the timed mutex operations require a win32 mutex object, while the mutex and try mutex can use a win32 critical section.
* On Win9x, the timed mutex and try mutex operations require a win32 mutex object, while the mutex can use a win32 critical section.
In other words, on the most widely-used platforms, collapsing the mutex types into one imposes some penalty (larger mutex object or more
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*. And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by. I feel that for the user having different types of mutexes is inconvenient and unnecessary 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 (as long as it does not impose performance penalties) -- memory is cheap and mutexes are not usually created in huge numbers. More so, I believe in boost there are techniques/classes minimizing waste. Best, V. limited
implementation options) on users. Also (I ask, not as a hypothetical question, but as a request for information): is there another platform where combining the mutex types incurs a similar or worse penalty?
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
participants (2)
-
Batov, Vladimir -
Michael Glassford