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

From: Eric Swanson (ESwanson_at_[hidden])
Date: 2000-09-14 13:58:41

> -----Original Message-----
> From: William Kempf [mailto:sirwillard_at_[hidden]]
> Sent: Thursday, September 14, 2000 12:47 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: thread lock/unlock example> 
> 
> There's reasons to prefer this over your suggestion, which I'll get 
> to later.  The point I'd make here, though, is that this is an 
> implementation detail of unsafe_lock<>.  This means several things.  
> For one, the fact that placement new is "icky" is irrelevant here, 
> since it's buried in the implementation.  For another, this means 
> that a different implementation of the same interface may very well 
> not use placement new (in fact, your example is just such an 
> alternate implementation).  In other words, since we're discussing 
> prototypes here the implementation details are mostly off-topic at 
> this stage.  They are only on-topic as the discussion pertains to 
> possible need for modification of the concepts.  My implementation, 
> whether you like placement new or not, is proof that a modification 
> of the concepts is not needed or warranted.
>  

My example can only be implemented if mutex<> knows about it.  It's not
merely an implementation detail if your implementation disallows extension.
Your implementation assumes that you know about every type of useful lock,
and that any other type of lock must be implemented in terms of
construction/destruction of your locks.

> 
> I really don't understand why the STL did this.  stack<> is not 
> designed for polymorphic behavior (no virtual d-tor) so the only 
> benefit this safely buys is the ability to access the container in 
> protected/private derivation.  I don't see how this could apply to 
> our current discussion.
> 

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.

> 
> Don't think in terms of implementation.  Think in generic terms of 
> the concepts.  This means that (a) isn't really an option.  Every 
> concrete implementation of the Mutex concept will have to have a 
> corresponding implementation (specialization?) of unsafe_lock<>.  
> Meanwhile, (b) is proof that a generic implementation of 
> unsafe_lock<> can be built solely using the Concept, with no reliance 
> on any implementation details.
> 

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.

> 
> A mutex_accessor<> would simplify development of various lock types, 
> but it would also expose the very methods that are so dangerous on a 
> mutex to begin with.  You might as well expose those methods directly 
> on the mutex.
> 

Not necessarily.  I was thinking of something like this:

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<>.

> 
> Why call it basic_varlock<>?  I can understand the basic_ prefix, but 
> varlock makes no sense to me.  In any event, I prefer "unsafe" 
> over "var" to add psychological emphasis that this is not the 
> preferred lock.

It's just a name.  I was thinking "var" because it's variable - sometimes
it's locked, sometimes it isn't.

> 
> As for why I prefer placement new... it's wholly generic.  It doesn't 
> require specialized coding when a programmer adds a new 
> implementation of a Mutex concept, nor does it impose any further 
> requirements on the implementation beyond those required by the 
> concept.  The feeling that it's "hackish" is irrelevant, since it's a 
> hidden part of the implementation.
> 

I'm suggesting that it might be possible, through use of mutex_accessor<>,
to provide an interface that can be extended more easily, without
sacrificing safety for basic use.

Eric Swanson