Re: thread lock/unlock example

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 17:32:41

--- In boost_at_[hidden], Eric Swanson <ESwanson_at_I...> wrote:
> > From: William Kempf [mailto:sirwillard_at_m...]
> > How is it inadequate?
> 
> What if I want an unsafe_trylock?  An unsafe_timedlock?  Another 
type of
> lock that you haven't thought of?  Construction/destruction of the 
3 lock
> classes that you've thought of is too thin an interface.

construction/destruction of the lock classes is an exact 1 to 1 
correlation to the three various lock/unlock functions you instead 
wish to expose in a mutex_accessor.  So they are no thinner than the 
mutex_accessor, and any lock class that can't be implemented in terms 
of these can't be implemented in terms of mutex_accessor either.  I 
don't buy your argument that the interface is "too thin".
 
> > That's precisely what I thought you meant.  However, 
mutex_accessor<> 
> > is publicly available, so it provides no added security (only a 
> > psychological one, which I suppose may be a valid argument... 
after 
> > all that's one reason why I'm ok with unsafe_lock<>).  Given that 
the 
> > thousand dollar question is why you just didn't expose this on 
mutex 
> > to begin with.
> 
> How does it provide no added security?  (No added security over 
what?) All
> of mutex_accessor<>'s methods are protected or private.  You have 
to derive
> from it in order to access the underlying mutex.  Are we protecting 
from a
> misinformed call to mutex.unlock(), or are we trying to keep 
someone from
> implementing a lock class without resorting to heroics?  You can't 
just
> instantiate a mutex_accessor<> and manipulate a mutex.  You derive 
from it
> in order to construct some sort of useful lock class.  I don't 
suggest
> exposing them on the mutex to begin with because that is an entirely
> different approach.

Sorry, I missed some of the nuances of what you're proposing.  It 
does make some sense and is basically what I've done with the nested 
impl classes, but turned inside out.  In my implementation I've 
completely made impl inaccessible to users because to do otherwise 
would expose functionality that's not part of the current Mutex 
model.  It might make sense to expose the class publicly, however, 
since as you pointed out the methods on it can be restricted to 
derived classes.  This will require other concepts to be defined 
(there won't be one MutexAccessor, because not all Mutexes support 
all lock types), but it does make sense.  I guess I've been so 
frustrated with the claim that the interface isn't complete because 
lock/unlock aren't exposed that I missed your point with this idea.

That said, all that MutexAccessor really does is provide us with a 
cleaner way of implementing locks than the placement new approach.  
It doesn't show that the interface is incomplete (or in your 
words, "too thin").

Bill Kempf