Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk