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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 10:54:41

Christopher Currie wrote:
> Michael Glassford wrote:
> 
>> So, would anyone care to summarize their take on what conclusions have 
>> been reached? I'm afraid I haven't had time in the last few days to 
>> respond much, or even to analyze everything as much as I would have 
>> liked; and in many cases, it's not obvious what conclusions were 
>> reached, if any. As far as I remember, the following topics have come 
>> up; undoubtedly I've missed something, so please add it to the list.
> 
> 
> The volume of messages with the original topic has become hard (for me 
> personally) to track, so I'll address each issue in a separate thread.
> 
>> Lock unification
>> ----------------
>> Should the three lock types (lock, try lock, timed lock) be combined 
>> into one?
>>
>> Conclusion: the lock class should be implemented as a single class 
>> templated on the mutex type; trying to use operations that the mutex 
>> doesn't support results in a compile error.
>>
>> Question: does this mean unification of the lock concepts, too?
> 
> 
> I've missed some of the arguments here, so can someone write up a good 
> rationale for this change? I'm not sure I'm convinced it's necessary. I 
> find that having separate types makes the sort of locking you're trying 
> to do more explicit and readable. The differences between
> 
> {
>   scoped_lock l( m );
> }
> 
> and
> 
> {
>   scoped_timed_lock l( m, t );
> }
> 
> are much more descriptive me than
> 
> {
>   scoped_lock( m );
> }
> 
> {
>   scoped_lock( m, t );
> }

Actually, it has been suggested to eliminate the latter constructor that 
takes a time as a parameter. There would only be one constructor:

    scoped_lock(Mutex m&, bool initially_locked=true);

which performs a blocking lock. Under this scheme, you would have to write:

    scoped_lock l(m, false);
    l.timed_lock(t);

> which would seem to require some implicit knowledge of the constructor 
> arguments.
> 
> I can infer that the apparent justification for unification would be to 
> allow a single lock to be used in different ways, but I have a hard time 
> imagining a use case where this would be as clear and as error-resistant 
> as separate scopes with separate locks. If anyone has one, or any other 
> rationale, please respond.

The main motivation behind the idea of unifying the lock types (and 
mutex types) is simplification of concepts, I believe.

Mike