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 pitrou
Recipients jcea, jyasskin, mark.dickinson, neologix, pitrou, sbt
Date 2013-03-22.15:48:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1363967306.85.0.0114334689805.issue17389@psf.upfronthosting.co.za>
In-reply-to
Content
> So in short, if wait() is called by a thread shortly after another
> thread clear()ed it, the former thread might very well read _flag ==
> True (while the later just set it to False) and return erroneously.

Would that be erroneous? It can already happen because of thread switches:
e.g. wait() reads True from the flag, then releases the internal lock;
another thread gets scheduled in, takes the lock and resets the event;
the original thread is resumed and the calling function sees True as
the wait() return value even though the event was reset in-between.

> Now, it's probably being pedantic, especially because we lack a
> memory
> model, but that bothers me.

As for the memory model, Jeffrey had written a PEP draft years ago:
http://code.google.com/p/unladen-swallow/wiki/MemoryModel

Unfortunately I can't find the corresponding reference in the python-dev
archives again.

That said, I agree the performance improvement is probably not important
here. It was just drive-by optimization on my part :-)
History
Date User Action Args
2013-03-22 15:48:26pitrousetrecipients: + pitrou, jcea, mark.dickinson, jyasskin, neologix, sbt
2013-03-22 15:48:26pitrousetmessageid: <1363967306.85.0.0114334689805.issue17389@psf.upfronthosting.co.za>
2013-03-22 15:48:26pitroulinkissue17389 messages
2013-03-22 15:48:26pitroucreate