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.