Antoine Pitrou <pit...@free.fr> added the comment: > Stolen wakeups are a fact of life though, even in cpython's > implementation of condition variables. And for the user of a > condition variable the difference is so subtle as to not warrant > special mention.
I don't think it's a subtle difference. Being woken up too late is not the same as being woken up spuriously. Also, the term "stolen wakeup" makes it unnecessarily dramatic. There is no "stealing" involved here. > Look anywhere in the internets and you will find this, including here: > http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html Thanks, will take a look. > Quite the contrary, we should be careful to never overspecify our > interfaces so that we may not change their ipmlementation details > later. The interface is already, de facto, specified by its one and only implementation, which has been in use for a long time. It's also specified by its documentation, before it was silently modified by you. There's probably code out there that relies on wait() not returning prematurately. > A good summary of the situation and the reason for the specification > can be found here: > http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups So the reason appears to be: “Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations.” Python is a high-level language, so making condition variable ops "substantially" slower is not a blocking issue for us. What follows is even less enlightening: “The intent was to force correct/robust code by requiring predicate loops. This was driven by the provably correct academic contingent among the "core threadies" in the working group, though I don't think anyone really disagreed with the intent once they understood what it meant.” > The comment I added to the documentation clarifies the reason why > other examples in the docs were using while loops and teaches shows > people how to use these constructs in a robust manner. Teaching people to use loops is fine. But there's no need to mislead them with inaccurate descriptions of the implementation's behaviour. > Unless you disagree, I'll add these test cases in addition to the > broken one, which can then be fixed or removed later if it turns out > to be problematic to other people. Really, can you stop being aggressive? You haven't proved that test is wrong, and it passes consistently fine on all buildbots. If you don't agree with what is being tested, that's another matter. But please accept that the test is ok w.r.t. Condition's specified behaviour. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8799> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com