On Feb 29, 12:55 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Thu, 28 Feb 2008 00:54:44 -0800 (PST), [EMAIL PROTECTED] declaimed > the following in comp.lang.python: > > > On Feb 28, 2:30 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > > > "It is time to show your cards or fold" > > > Here. Run it. Download Python 3.0a2. > > I'm unlikely to download an alpha release when I haven't even > upgraded to 2.5 (maybe the next three day weekend I'll have time to > track down new versions of all the third party modules I have installed > and then download 2.5) > > But I'll meet you half-way > [snip] > The RESET is the one executed as part of initializing the StepLock > member of Worker. Even though thrd.start() is invoked, it is likely the > thread does not gain control at that point. That would mean the ACQUIRE > 0 is the one in the range(5) loop, along with the NOTIFY and RELEASE, > followed by calling op100. ACQUIRE 5 is a result of the acquirestep(0). > NOW the thread actually gained control (worker entered) and ACQUIRE 8 8 > are part of its acquirestep(1). The thread actually gets the condition > lock immediately, tests the current step level against the step is want > and finds a mismatch. The thread then signals for any other thread > waiting on the condition via NOTIFY, and then waits for another thread > to trigger a notify on it (WAIT 12). Control returns to op100 and the > acquirestep(0) ACQUIRE 5 is answered with 5 taken; the step level > matches the desired step, and the code for step 0 is executed...
Pretty cool. First, thanks for taking the time to -edit- my code, along with getting it running! I appreciate your effort. And I'm happy you like it enough to put it in. It runs on my machine in 2.5. First change was to run it indefinitely, and it's doing so. Still not conclusive evidence that it's free of deadlocks, nor is that I don't see any by inspection. ...But it's running. Second, thanks for picking better names for the identifiers. Mine always suck. Third. StepLock.acquirestep can use notifyAll: wake all of them up, and all but one go back to sleep. However, the current implementation wakes them up in order wait was called, so you do save some time here, (Even though the docs say otherwise). The while self._step!= step is suspicious, but the alternative is an -sequence- of locks, the penalty is only large for high step lengths, and it's not exactly polling-- so maybe that's just the purist in me. Fourth: wait is a private member, unless you're enabling the functionality of waiting for the next change in step by another thread. notifyAll isn't used anywhere. condition is also private, I believe. Fifth: My webreader gives me this information: "Note: The author of this message requested that it not be archived. This message will be removed from Groups in 6 days (Mar 7, 12:55 am)." Curious if you intentially have it. It could be nice to retrieve this-- same with Stage. Sixth: If I comment out fmain:worktask.slock.release() and threadbody:worker.slock.release() there is no effect. It's bizarre. Is it a requirement to use them? Seventh: What is the advantage of using a Condition over an Event? -- http://mail.python.org/mailman/listinfo/python-list