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 );
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
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]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk