Re: [boost] Re: Lock unification [move]

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-07-19 14:54:02

From: "Peter Dimov" <pdimov_at_[hidden]>
> Rob Stewart wrote:
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >>
> >> Also, I still think that the bool parameter is better than a
> >> "locking" enum, as evidenced by the use case shown in the
> >> specification:
> >>
> >>     scoped_lock lock( m, want_to_lock? locking: non_locking );
> >>
> >> I find this an unnecessarily verbose and contrived way to express
> >>
> >>     scoped_lock lock( m, want_to_lock );
> >>
> >> which is the original intent.
> >
> > I disagree.  From the perspective of calling code, using a bool
> > makes things more confusing:
[snip]
> > From this context, it isn't apparent what "true" and "false"
> > mean.  Yes, you can refer to the documentation, but what if
[snip]
> > With the enum, however, the code is self-documenting:
> >
> >    scoped_lock lock1(m, locking);
> >    scoped_lock lock2(m, non_locking);
> >
> > Thus, using the enum eliminates a source of errors and confusion
> > whereas the conditional behavior you mention is still possible,
> > if verbose.
> 
> You could have written that about any interface that takes a bool. Perhaps

Exactly.

> if you take into account some specific properties of scoped_lock you'll be
> able to argue more convincingly. For example:
> 
> - a 'locking' lock is actually spelled
> 
>     scoped_lock lock1( m );

Then why wasn't the example written like this?

   scoped_lock lock(want_to_lock
      ? scoped_lock(m)
      : scoped_lock(m, non_locking));

That was a rhetorical question (IIRC, and I'm not following this
discussion closely, scoped_locks are not copyable, so you can't
write this version).

> - the conditional behavior was actually in Howard's specification as the use
> case for the constructor, it wasn't merely mentioned by me;

OK, but you used it as the basis for justifying using bool
rather than the enum.  I'll grant you that I didn't have the
whole picture to which you were apparently alluding; I just took
your statements at face value.

> - the non-locking case:
> 
>     scoped_lock lock2( m, false );
>     scoped_lock lock2( m, non_locking );
> 
> usually crops up when lock2 is about to be try_locked or timed_locked
> immediately thereafter. If we include
> 
>     scoped_lock try_mutex_lock( Mutex & m );
> 
> that enable Eric Niebler's
> 
>     if( scoped_lock lock2 = try_mutex_lock( m ) )
> 
> this will reduce the frequency of the "non-locking locks" considerably.

Doesn't that argue for the case of making the "key" that
indicates that the lock should be "non-locking" more explicit
than a bool?  IOW, if one is rarely going to write
"scoped_lock(m, false)," then the meaning of "false" is even more
obscure and "non_locking" is even more appropriate.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;