Re: thread lock/unlock example

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 12:47:13

--- In boost_at_[hidden], Eric Swanson <ESwanson_at_I...> wrote:
> What I'd like to see is a lock template something like this one.  
Yes, the
> placement new solution used by unsafe_lock<> works, but it sure 
seems to me
> like it's digging too deep into the bag of tricks.   

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.
 
> It might be useful to take a cue from the STL: stack<>'s 'Cont c' 
member is
> protected, not private.

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.

>  Due to the exclusivity of the mutex interface, it
> seems unlikely one would be able to write a lock template like this 
one
> without either a) hacking mutex.h, or b) using placement new, which 
seems
> hackish to me.

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 might be useful to have some sort of 'mutex_accessor'
> class so that implementing a new lock<> template wouldn't require 
adding a
> friend to the mutex class (or using placement new).

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.

> template <typename M>
> class basic_varlock

[snip]

This is unsafe_lock<> to a T, it just uses friendship instead of 
placement new in the implementation.  This leaves me with a question 
and then an explanation of why I'd prefer the placement new "hack".

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.

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.

Bill Kempf