From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-15 18:42:16
On Thu, 15 Jul 2004 17:23:40 -0400, David Abrahams
> What about:
> scoped_lock l(m); // block
> scoped_lock l(m, 0); // try
> scoped_lock l(m, 33); // timed
> scoped_lock l(m, deferred); // deferred
> scoped_lock l(deferred(m)); // alternate
Seems neat. A deferred timed lock make sense, but not in this context
you are deferring, I assume, the locking strategy rather than the
lock, or do I have that wrong... it's been a long threading thread ;-)
I'm not sure I see the case for deferring anything a stack based
scoped lock with a:
void folly ()
is still preferable to me than allowing explicit locking of a lock.
I worry about paying for the overhead, perhaps in space for a scoped
time lock that records it timing versus a blocking lock that needs no
such information, but I'm not sure that it is a big deal as the
difference is negligible and these will typically be stack based.
Implementation will reveal all I guess.
As I've mentioned previously, it would be nice to consider this
interface in the general sense of the two concepts:
As this is equally applicable to mutex, lock and socket, packet, etc...
Perhaps such a generalization makes the explicit locking of a lock
more worthwhile?? I'd have to see the code...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk