Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at