Re: [boost] Re: Lock unification

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);
       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