On Thu, 15 Jul 2004 17:23:40 -0400, David Abrahams <dave@boost-consulting.com> 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); do_stuff(); } { scoped_lock l(m); do_more_stuff(); } } 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... Regards, Matt Hurd