Batov, Vladimir wrote:
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(); }
I think that you have that backwards. If the only use case for 'nolock' is the example above, then the bool argument is obviously an improvement. The 'nolock' version needs a rationale, not the bool version.
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.
No, this is not correct. timed_lock is a refinement on both lock and try_lock, because it is-a lock (with time=infinite) and a try_lock (with time=0). The reverse is not true.