is there enough information?

[castironpi at gmail.com]

On Feb 29, 12:55 am, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
> On Thu, 28 Feb 2008 00:54:44 -0800 (PST), castiro... at gmail.com declaimed
> the following in comp.lang.python:
>
> > On Feb 28, 2:30 am, Dennis Lee Bieber <wlfr... at ix.netcom.com> 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?