niels at endea.demon.nl
Mon May 15 12:34:26 EDT 2000
Ben Wolfson schreef:
> Ah. I was under the impression that calling wait() counted as a
As I understand it, it just 'suspends' your claim on the lock and then
restores it when the wait finishes.
> >BTW, don't you think that this is a rather complicated way to emulate
> I might if I knew what they were.
Coroutines are a simple way to do pseudo-parallel programming. One
routine starts out, then when it's done for the moment it saves its
current state and calls the other one. When the second routine has no
more to do, it saves its state and jumps back to where the first one
left off. So they go on transferring control back and forth. It's a good
way to write programs in a parallel style, without the overhead and
debugging headaches of real threads.
My point was, because both threads aquire() at the beginning, and only
release() at the end, each thread can only run while the other is in its
wait(). Therefore they will never be able to do anything in parallel,
even if you would remove the extra aquire()s.
On the other hand, if you would release and reaquire the lock within the
loop, I think you couldn't be sure that the other thread was in wait()
when you notify(), so the whole thing might deadlock. (I might be wrong
I'm not sure you can do this type of thing (taking turns at something)
in any useful way (such that you can do part of the work in parallel)
with a Condition. If you find a solution, please let me know. Two Locks
would be easier, I guess.
More information about the Python-list