bool foo(bool threadsafe) { mutex::scoped_lock l(m, !threadsafe); }
I am not sure if the example above is appropriate and indicative of the problem we are trying to solve. Thread-safety should not be a run-time configurable property. Like we do not decide on the fly (at run-time) if our ref.-counting class is to be thread-safe or not. All that is resolved at compile time. More so, that still can be solved with statically defined lock/nolock constructors: bool foo(bool some_condifion) { mutex::scoped_lock l(m, boost::nolock); if (some_condition) l.lock(); } 2. I feel that our assumptions of try_lock (yes, I know it is try_scoped_lock, I am just lazy) and timed_lock being refinements of scoped_lock are incorrect. At best scoped_lock and try_lock are refinements of timed_lock as scoped_lock is timed_lock with time=infinite and try_lock is timed_lock with time=0. Therefore, we you insist on common lock functionality, it has to be encapsulated in one timed_lock (or maybe some basic_lock or just a lock). Then, all locks would refine that common behavior. That approach has the advantage of covering the case when I do not know what I want :-) -- then I'd simply use the basic_lock. 3. However, I personally feel that our attempts of generalizing locks are misguided. Locks are different, serve different purposes and provide different and distinct functionality. I feel that we should make an effort to keep different locks different and lean. Like try_lock actually tries to lock. Adding blocking (lock()) functionality to such a lock looks like a mistake as IMHO it encourages bad programming style as it allows to use try_lock where scoped_lock is needed. I feel that the situation when I do not know what kind of lock I need when I step into a function shows that the function needs to be-restructured/split so that in every new component I do know what I need. V.