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?