Michael Glassford <glassfordm@hotmail.com> writes:
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 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?
If the difference is in the code that must be generated within the locking function, I'd guess that the differently-named functions can handle it. If the difference is in the data stored in the mutex and/or the lock, it could be an issue. You might be able to use boost::variant to minimize storage. It would be worth doing some experimentation to see whether optimizers can make the other overheads disappear. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com