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 kristjan.jonsson
Recipients brian.curtin, kristjan.jonsson, loewis, pitrou, sbt, tim.golden
Date 2011-03-21.20:12:28
SpamBayes Score 8.0383565e-05
Marked as misclassified No
Message-id <1300738349.54.0.973775451739.issue11618@psf.upfronthosting.co.za>
In-reply-to
Content
There is no barrier in use on the read part.  I realize that this is a subtle point, but in fact, the atomic functions make no memory barrier guarantees either (I think).  And even if they did, you are not using a memory barrier when you read the 'timeouts' to perform the subtraction.  On a multiprocessor machine the two values can easily fall on two cache lines and become visible to the other cpu in a random fashion.  In other words:  One cpu decreases the "owner" and "timeouts" at about the same time.  A different thread, on a different cpu may see the decrease in "owner" but not the decrease in "timeouts" until at some random later point.

Lockless algorithms are notoriously hard and it is precisely because of subtle pitfalls like these.  I could even be wrong about the above, but that would not be blindingly obvious either.  I'm sure you've read something similar but this is where I remember seeing some of this stuff mentioned:  http://msdn.microsoft.com/en-us/library/ee418650(v=vs.85).aspx
History
Date User Action Args
2011-03-21 20:12:29kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, pitrou, tim.golden, brian.curtin, sbt
2011-03-21 20:12:29kristjan.jonssonsetmessageid: <1300738349.54.0.973775451739.issue11618@psf.upfronthosting.co.za>
2011-03-21 20:12:28kristjan.jonssonlinkissue11618 messages
2011-03-21 20:12:28kristjan.jonssoncreate