Re: boost::mutex::scoped_lock conventions

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-05-14 18:32:19

Christopher Currie wrote:
> This question sparked another "usage convetion" question in my memory
> that came up around the office lately. I've been slow introducing the
> members of my development team to a subset of Boost.Threads and trying
> to get them to use RAII thinking when implementing their locks.
>
> There seem to be two schools of thought on how to synchronize access
> to a class. One school, primarly from the developers who have
> experience in Java, tend to write classes that do their own mutex
> locking: snipped...
> The Callee lockers believe that is more important for the class to
> implement the locking, because the class knows what data it has that
> requires synchronized access, and that putting the locking inside the
> class means that you only have to get it right once. The Caller
> lockers argue that adding locks to all your class functions
> introduces overhead that is unnecessary if you never share instances
> between threads, and that making the locking explicit in the caller
> makes it somewhat easier to prevent, or at least track down, deadlock
> errors.
>
> Is there a community consensus about this? I can imagine that there
> are cases where either might be appropriate, but I'd like to hear
> peoples experiences with both implementations.

I think the Callee approach is the right one if the class might need a lock.
However, I would combine this with an approach which allows the Caller to
turn on or off the Callee's internal locking ability. It does seem silly to
require the Caller to implement necessary locking in a class each time when
the Callee can implement it once and allow a simple function call to turn it
on or off.

OTOH, as a Callee, I would need to be very sure that the usage of my class
really needs locking in a multi-threaded envrionment before I implemented
the necessary locking as an option of my class. And of course I would use
whatever preprocessor information I could gather for my code to make sure
that I do not include my implemented internal locking when my class's
functionality is compiled for a single-threaded environment.