Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-06-30 06:36:24

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.