> -----Original Message-----
> From: William Kempf [mailto:sirwillard@my-deja.com]
> Sent: Thursday, September 14, 2000 5:33 PM
> To: boost@egroups.com
> Subject: [boost] Re: thread lock/unlock example
>
> 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".

Ah, I see your point - more below. 

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

Interesting - I hadn't considered changing the 'impl' structure along with introducing the mutex_accessor<>, but you're right, it would make it possible to put the semaphore and all directly in the mutex (all private).  I put all the *lock calls in one mutex_accessor<> because I thought the template methods would only be instantiated if they're called.

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

You're right - the interface isn't incomplete, all the functionality is there.  I guess what I meant was that the placement new approach is a bit further from "say what you mean" than I'd prefer.  But that's just a matter of personal preference.

Eric Swanson