Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-22 15:06:32

--- In boost_at_[hidden], jsiek_at_l... wrote:
> William Kempf writes:
> > I think you're jumping to conclusions. There may be a way to
> > the lock_pointer using the MutexLock (I'd bet there is, I just
> The only way I see is to dynamically allocate the lock object, which
> is something we were thinking about disallowing.

*chuckles* You beat me to the punch here. I posted sample code with
out first seeing this.

I don't know that I agree with disallowing locks on the heap. It
does protect us from some sticky issues, such as deleting the lock
from a thread that doesn't own it, but I can also see valid reasons
for placing it on the heap. However, see below.

> > haven't worked on it yet). Even if not, all that's really
needed is
> > to make the lock_pointer a friend of the Mutex, the same as is
> > for the MutexLock. I see no reason to expose the lock/unlock
> > of the mutex on the public interface.
> That might work... though this could be a slippery slope, where the
> friend list inside the mutex classes keeps growing and growing...

That all depends. So far the list isn't very large, though I do see
the possible danger. The slippery slope, however, isn't a good
enough reason to expose these dangerous methods. Actually, a better
solution to this specific problem is to allow locks to be copied!
Some simple reference counting will insure that the associated mutex
is only unlocked once, or if recursive mutexes are allowed we could
simply lock the mutex again during a copy. Another option would be
to have the copy act like an auto_ptr copy, transferring ownership
completely. The only danger then becomes the same as we had with the
pointer... the possibility of destruction in a thread that doesn't
own the lock. I think that danger is small enough that I could live
with it. What do you think?

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at