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@gmail.com>