I was thinking that the lock enforcement would be handled server side, but i don't know how you would allow for dynamic semaphores without doing most of the work client side.
That's always been one of the problems with parallel programming at the basic level. If the clients don't play nice, you're completely screwed. The require syntax makes sense but I can see a lot happening inside of a lock segment. I think that the new features in the 0.25 series will make it pretty much a non-issue though as you should be able to make an entire class depend on the semaphore resource, correct? I'm quite happy that you're taking an interest in this. I think that it could be a quite powerful addition to the core, but don't have the time to really try and work on it. I can see this possibly growing in the future to encompass a range of cross-environment/enterprise transport layers and back-end databases. Thanks, Trevor On Fri, Jun 4, 2010 at 12:15 PM, David Schmitt <[email protected]> wrote: > On 6/4/2010 1:03 PM, Trevor Vaughan wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Completely agree with the issue of lock contention. >> >> You would probably have to provide the capability to have optional lock >> overrides or timeouts. >> >> So...something like: >> >> # Grab a semaphore for the '$dataserver/bar' data >> # Timeout after 5 seconds >> # Skip requiring stanza if lock cannot be obtained. >> >> semaphore { "$dataserver/bar": >> timeout => '5', >> fail_mode => 'skip' >> } >> >> lock(Semaphore["$dataserver/bar"]) { >> ...do fancy stuff... >> } > > I'm not convinced that this should be handled client side. And I'm pretty > sure you'd want to use the existing require/before syntax to specify the > dependencies on locks. > > > Best Regards, David >> >> Trevor >> >> On 06/04/2010 04:33 AM, David Schmitt wrote: >>> >>> On 6/3/2010 3:54 AM, Trevor Vaughan wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I've been following this thread with interest and I think that Donavan >>>> is hitting upon something that I've also been wanting. >>>> >>>> However, the way I was looking at it was as a set of atomic, optionally >>>> blocking, semaphores in a set of parallel threads. >>>> >>>> If you look at each puppet client as an individual thread and realize >>>> that you need things to happen cross-client that depend on the state of >>>> one or more clients, then you've deconstructed this into a classic >>>> parallel programming application (with all the constituent nonsense). >>> >>> Interesting perspective! Especially as this allows one to re-use the >>> existing research to evaluate the pitfalls of such an approach. >>> >>> >>> Deadlocks can be circumvented by partially aborting transactions (i.e. >>> failing dependend resources) instead of locking. >>> >>> Serializability is not really a concern of puppet, since we have >>> eventual convergence. >>> >>> A more complex problem in our case would be contention of locks (e.g. >>> when used for orchestrating a N-out-of-M rollout). I'm thinking of >>> thundering herd problems or often repeated and aborted transactions. >>> >>> >>> >>> Best Regards, David >> >> - -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc. >> email: [email protected] >> phone: 410-541-ONYX (6699) >> pgp: 0x6C701E94 >> >> - -- This account not approved for unencrypted sensitive information -- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iEYEARECAAYFAkwI3YEACgkQyWMIJmxwHpR1QQCeKXDNYYAbeffliuTl+0aWrYQC >> SnsAoLOMBqXPXpxCBSalxjaB7ikaD0M9 >> =LafK >> -----END PGP SIGNATURE----- >> > > > -- > dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at > Klosterneuburg UID: ATU64260999 > > FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
