Re: Threads

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 
code 
>  > 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 
done 
>  > for the MutexLock.  I see no reason to expose the lock/unlock 
methods 
>  > 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