Re: [Boost-users] Lock pointer implementation

From: Mattias Brändström (thebrasse_at_[hidden])
Date: 2006-09-11 03:40:35

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_ptr<boost::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