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

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 10:15:44

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 );
}

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.

-- 
Christopher Currie <codemonkey_at_[hidden]>