On Fri, 23 Jul 2004 09:30:39 +1000, Matt Hurd <matt.hurd@gmail.com> wrote:
On Fri, 23 Jul 2004 01:22:48 +0200, Alexander Terekhov <terekhov@web.de> wrote:
Matt Hurd wrote:
On Fri, 23 Jul 2004 08:31:18 +1000, Batov, Vladimir <vladimir.batov@ca.com> 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.