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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-06-29 17:08:57

> 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.