Boost logo

Boost :

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
<dave_at_[hidden]> wrote:
> 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 ()
       scoped_lock l(m);

       scoped_lock l(m);
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:
    1) resource
    2) acquisition
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...


Matt Hurd

Boost list run by bdawes at, gregod at, cpdaniel at, john at