Sebastian Redl wrote:
On Thu, September 7, 2006 8:38 am, Mattias Brändström wrote: I've played with this thought several times in the past. In the end, what made me never implement it is the fact that it locks and unlocks the mutex for every single operation on the class. If you call more than one operation in sequence, that's not exactly efficient. That said, for classes that have only operations which you usually don't call in sequence, the pointer is quite useful. I have just one change: there is no reason to allocate the lock dynamically.
For some reason most of my classes that ar thread safe handles locking in a similar way to the LockPointer, locking a mutex for each method call. I don't like exposing the thread safety so to speak. But I can definitely see your point in that being inefficient some times. Another small thing I have come to think of is the case where the pointed to class call itself as a result of a method call thru thru the lock pointer. In these cases a second lock will not be created as it would if I had implemented locking within the class itself. However, I can't think of any cases where this will cause any problems.
class LockProxy { public: LockProxy(boost::shared_ptr<T> p, boost::shared_ptrboost::recursive_mutex mutex) : p_(p), lock_(*mutex) { }
const boost::shared_ptr<T> &operator->() { return p_; }
private: boost::shared_ptr<T> p_; boost::recursive_mutex::scoped_lock lock_; };
I've also changed the return type of operator ->. There's no need to create a copy of the shared_ptr.
I'll use these changes in my implementation. :.:: mattias