> -----Original Message-----
> From: William Kempf [mailto:sirwillard@my-deja.com]
> Sent: Thursday, September 14, 2000 4:39 PM
> To: boost@egroups.com
> Subject: [boost] Re: thread lock/unlock example
>
> > I mentioned it as an example of an inclusive, or humble,
> interface.  It
> > allows the programmer access if needed, but discourages misuse
> through
> > protected access.  It doesn't assume that the library designers
> have thought
> > of every possible use.  It also shows a precedent in the STL for
> allowing
> > more access through derivation.
>
> It doesn't apply here, though.

Ah, okay.

> >
> > It's relying on the interface.  The only interface provided is
> > construction/destruction.  Just because unsafe_lock<> can be
> implemented
> > with the existing interface doesn't mean that the interface is
> adequate.
>
> 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.

> >
> > template <typename M>
> > class mutex_accessor
> > {
> > private:
> >     mutex_accessor(const mutex_accessor&);
> >     operator=(const mutex_accessor);
> >
> > protected:
> >     mutex_accessor(M& mx) : m_mx(mx.m_mx) {}
> >     ~mutex_accessor() {} // intentionally nonvirtual
> >
> >     void lock() { m_mx.lock(); }
> >     bool trylock() { return m_mx.trylock(); }
> >     bool timedlock(int milliseconds) { return
> > m_mx.timedlock(milliseconds); }
> >     void unlock() { m_mx.unlock(); }
> >
> > private:
> >     M::impl& m_mx;
> > };
> >
> > Now, if I were to think of a useful lock type that you hadn't
> thought of, I
> > could implement it by deriving from mutex_accessor<>.
>
> 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.

>
> I understand what you're saying, but I think this is no different
> from exposing this functionality on mutex directly.
>

But it is quite different.  The mutex_accessor<> grants access only to derived classes.  basic_lock<M>, basic_trylock<M>, and basic_timedlock<M> would be examples.  If someone thinks of a lock template that you haven't thought of, they can derive from mutex_accessor<> to implement it.  This is different from granting blanket access to mutex.lock() and mutex.unlock().

Maybe you can explain how mutex_accessor<> grants too much access?

Eric Swanson