From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 12:24:01
Peter Dimov wrote:
> The "unified" timed lock case is
>
> {
> scoped_lock l( m, false );
>
> if( l.timed_lock( t ) )
> {
> // do stuff
> }
> else
> {
> // what do we do here? presumably either:
>
> // setup for unbounded wait
> l.lock();
> // do stuff
>
> // or signal failure
> }
> }
I understand this is just an example, but the question I find myself
asking is: if a blocking lock is acceptable, why not do it in the first
place?
However, let's assume that for some performance reason we'd like to see
if we can get the lock quickly, and if not, then do the (potentially
expensive) setup we need to allow for a blocking lock. The timed_lock
class supports the above scenario as-is. And even if it didn't, the
behavior could still be done:
bool done = false;
{
scoped_timed_lock l( m, t );
if ( l.locked() )
{
// do stuff
done = true;
}
}
if ( ! done )
{
// setup
scoped_lock l( m );
// do stuff
}
Granted, this may seem a bit more cumbersome to the user, which is why
the scoped_timed_lock class has a blocking lock() operation built in.
> The scoped_timed_lock use case also needs to eventually contain an if( l )
> statement; you can't do much if you don't know whether your timed lock
> succeeded.
Agreed.
> One might also argue that a separate scoped_timed_lock makes
> accidentally omitting the if() statement more likely and harder to spot.
I can see that, although one could also argue that the name of the
scoped_timed_lock class is an immediate signal that one needs to check
the status of the lock.
It does feel like a matter of preference, though; I prefer to use the
locking constructors as opposed to the non-locking constructors.
Fortunately, the scoped_timed_lock supports either usage as-is, without
modification.
> But it's hard to tell without real use cases.
Agreed.
-- Christopher Currie <codemonkey_at_[hidden]>