[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 11:38:58

David Abrahams wrote:

> Michael Glassford <glassfordm_at_[hidden]> writes:
> 
> 
>>The point being that TryLock is a refinement of Lock, and TimedLock is
>>a refinement of TryLock? If so, I agree that's better than TryLock and
>>TimedLock both refining Lock. There are still the constructor issues
>>to deal with in such a lock taxonomy, however. The main one: how do
>>you define destructors that are consistent within a lock concept and
>>also consistent between concepts. E.g., on the one hand it seems that
>>a one-parameter constructor should do the same thing in all lock
>>types--so it would have to block; on the other hand, it seems that
>>TryLock constructors should not block unless instructed to do
>>otherwise.
> 
> 
> One possible answer is that construction protocol simply isn't part
> of the concept taxonomy.
> 
> Another possible answer might lie in considering syntax alternatives
> for lock construction.  For example, a named parameter interface:
> 
>   Lock l(block = m);
> 
>   TryLock l(block = m);
>   TryLock l(proceed = m);
> 
>   TimedLock l(wait = m, t);
> 
> That particular expression of the idea is probably too cute, 

It is an interesting idea, though.

 > but I'm just trying to expand the boundaries of thought.

I appreciate that; I've been trying to think of alternatives, but hadn't 
considered named parameters.

Mike