From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 09:15:31
Batov, Vladimir wrote:
> Could we please resist complicating interfaces when we do not have to? I
> personally consider an additional blocking parameter for something like
> try_lock excessive because it distorts try_lock into becoming
> scoped_lock. Let's keep different concepts different. Blocking in
> try_lock is an oxymoron -- try_lock cannot block because it is "try".
Perhaps I would agree, except that try_lock already has a lock() method,
which, by design, blocks. To rephrase what Christopher pointed out, a
scoped_try_lock is nearly the same as a scoped_lock with try_* methods
added (I say nearly because the constructors are different, which is
partly what I'm trying to address).
> The basic usages (covering about 80%) are:
> scoped_lock l(m); // Block until it locks.
> scoped_try_lock l(m); // Try (!) to lock. I'll check the result.
> scoped_timed_lock l(m, time); // Block until it locks or time runs out.
> I'll check the result.
> Simple and clean.
True. It's also simple and clean to say that a try_lock is a lock with
added functionality, and a timed_lock is a try_lock with added
> The only functionality that I can see beyond that is
> when I have to only declare a lock but apply it later. Like:
> scoped_lock l(m, do_not_lock);
> if (something)
> l.lock(); // Can't declare here.
> For that purpose we'll need something like
> scoped_lock(mutex&, nolock_t);
I'm increasingly liking this syntax, by the way; thanks for suggesting it.
> That's it. Isn't it?
> Alternatively we might consider making timed_lock our basic lock as
> scoped_lock and try_lock are merely border-cases (time=infinite and
> time=0 respectively). Then, scoped_lock and try_lock would be real
> refinements (convenience interfaces) of that general concept.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk