This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ysj.ray
Recipients kristjan.jonsson, loewis, pitrou, ronaldoussoren, ysj.ray
Date 2010-04-19.11:40:33
SpamBayes Score 1.6834117e-10
Marked as misclassified No
Message-id <1271677235.99.0.031419356566.issue8410@psf.upfronthosting.co.za>
In-reply-to
Content
Hi, 

krisvale:
> Since the exact mechanics seem to be unclair to many, let me just step you through the series of events.
> 1) A has the lock, B is waiting for it.  the bit is "set".
> 2) A releases the lock:  Clears the bit, signals the condition variable.
> 3) A tries to immediately reacquire the lock.  Sees the bit cleared, sets it, and claims the lock.
> 4) B wakes up from the condition variable.  Sees the bit "set" and goes back to sleep.  It has lost the race to A.

I don't quite understand the four steps you explained. After the time of step 2, B is going to waken up and acquire the lock, and at the same time A returns from release function and is going to reacquire the lock. Who is scheduled first after A signals the condition variable is not predictable. So why does A always acquire the lock?

Thanks!
History
Date User Action Args
2010-04-19 11:40:36ysj.raysetrecipients: + ysj.ray, loewis, ronaldoussoren, pitrou, kristjan.jonsson
2010-04-19 11:40:35ysj.raysetmessageid: <1271677235.99.0.031419356566.issue8410@psf.upfronthosting.co.za>
2010-04-19 11:40:34ysj.raylinkissue8410 messages
2010-04-19 11:40:33ysj.raycreate