RE: [boost] Re: thread lock/unlock example

From: Eric Swanson (ESwanson_at_[hidden])
Date: 2000-09-14 17:05:57

> -----Original Message-----
> From: William Kempf [mailto:sirwillard_at_[hidden]]
> Sent: Thursday, September 14, 2000 4:39 PM
> To: boost_at_[hidden]
> 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