Boost logo

Boost :

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,
> > is publicly available, so it provides no added security (only a
> > psychological one, which I suppose may be a valid argument...
> > all that's one reason why I'm ok with unsafe_lock<>). Given that
> > thousand dollar question is why you just didn't expose this on
> > 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
> 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
> 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

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