Re: [boost] Re: Lock unification [move]

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-22 19:38:39

On Fri, 23 Jul 2004 09:30:39 +1000, Matt Hurd <matt.hurd_at_[hidden]> wrote:
> On Fri, 23 Jul 2004 01:22:48 +0200, Alexander Terekhov <terekhov_at_[hidden]> wrote:
> >
> >
> >
> > Matt Hurd wrote:
> > >
> > > On Fri, 23 Jul 2004 08:31:18 +1000, Batov, Vladimir
> > > <vladimir.batov_at_[hidden]> wrote:
> > > > How 'bout
> > > >
> > > > scoped_lock lk1(m, defer);
> > > > scoped_lock lk2(m, try);
> > >
> > > no comment except that perhaps scoped_lock can be dropped for just
> > > lock.  scoped_lock seems so twentieth century ;-)
> >
> > Yeah. And I'm sick and tired of all these "lock" verbs and nouns.
> >
> > guard g1(m, disengaged);
> > guard g2(m, try_engage);
> >
> > Oder? ;-)
> >
> > regards,
> > alexander.
> 
> a mutex is often referred to as a guard and having a lock called a
> guard is not ideal IMO.
> 
<snip> 

Naming a lock anything but a lock is a helluva lot of current to swim against...

A lock is common and understood but, like you, I'm not a fan of it
because of the verb and nouns confusion you point out.  Too many times
have I landed at a workplace with mutexes called locks exposing a lock
and unlock method :-(

It would be nice to rename it, but impractical and might impede
learning I think.  A typedef of the "preferred" name to lock might
suffice though??

I would love to keep a consistent nomenclature for other similar
patterns, e.g. socket, file and timer interaction but my language
skills let me down in trying to coming up with an appropriate name for
the "acquirer" / lock.

Resource and acquirer are the concepts with the action being an acquisition
   acquirer a(r, technique) ;

Deferment is confusing to me as this could be related to deferring the
the technique specification or deferring the acquisition action.  Both
make sense.  Also specifying the technique when the action is deferred
is, perhaps, just setting up defaults that can be overridden at the
action site.

Named parameters might help make the specification of the acquisition cuter.

   acquirer a(r, spec, deferred = true );      // named_params ?
    ...
   a.do(spec);   // do, execute, 

or perhaps, cleaner...

   a(spec);  // returns true for success which can be ignored
depending on your idiom

Also if you defer the action you could still wish to specify the
technique at the site of the acquisition.  E.g. try_locking with
exponential time decay in a loop.

   1.  defer spec of action and the actual action
   2.  defer the action

Is choice of deferment of the action really required at run-time?  If
not then perhaps different types would be better.
   
   acquirer_deferred a(r, spec);
   acquirer a(r, spec);

Hmmm, dunno.  One certainty though, the name "acquirer" certainly sux.

Similar concepts could apply for file, socket, timer and other
interaction.  Would be nice to keep the conceptual framework for this
clean and orthogonal if a way can be found.

Code management might be an issue without Mike's / David Held's policy
approach.  Say if you wanted to add a spin_acquiring method for
resource acquisition.  You should be able to do this cleanly and allow
for specialization for os / resource specific optimization. 
Interestingly, perhaps such a technique could apply equally well to
socket and mutex acquisition from the one code point.  The
extensibility of the scheme should be clear.  I'm not sure it is with
scoped_lock lk( m, new_thing );

<$0.02,

Matt Hurd.