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

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

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