[issue17389] Optimize Event.wait()

Antoine Pitrou added the comment: Agreed. -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-li

[issue17389] Optimize Event.wait()

Mark Dickinson added the comment: [Antoine] > That said, I agree the performance improvement is probably not important > here. It was just drive-by optimization on my part :-) Shall we close this as rejected? -- ___ Python tracker

[issue17389] Optimize Event.wait()

Charles-François Natali added the comment: > Would that be erroneous? It can already happen because of thread switches: That's not really the same thing. wait() would return True, which is the right thing to do since the Event has been set at some point. Here, it would make it possible for wait(

[issue17389] Optimize Event.wait()

Richard Oudkerk added the comment: On 22/03/2013 3:31pm, Charles-François Natali wrote: >> I was under the impression that dict access (and therefore attribute >> access for "simple" objects) was guaranteed to be atomic even in >> alternative implementations like Jython and IronPython. >> >> Is t

[issue17389] Optimize Event.wait()

Mark Dickinson added the comment: Charles-François: would your objections also apply to the current implementation of 'is_set'? -- ___ Python tracker ___ ___

[issue17389] Optimize Event.wait()

Antoine Pitrou added the comment: > 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 becau

[issue17389] Optimize Event.wait()

Charles-François Natali added the comment: > I was under the impression that dict access (and therefore attribute > access for "simple" objects) was guaranteed to be atomic even in > alternative implementations like Jython and IronPython. > > Is this not a language guarantee? AFAICT there's no s

[issue17389] Optimize Event.wait()

Richard Oudkerk added the comment: On 22/03/2013 3:19pm, Charles-François Natali wrote: > The _flag is checked without any lock held: although it won't be a > problem with CPython, a standard memory model (e.g. Java's one) > doesn't guarantee that reading _flag outside of the lock will return > t

[issue17389] Optimize Event.wait()

Charles-François Natali added the comment: Something bothers me: """ def wait(self, timeout=None): if self._flag: return True self._cond.acquire() """ The _flag is checked without any lock held: although it won't be a problem with CPython, a standard memory model (e.g. Java's on

[issue17389] Optimize Event.wait()

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue17389] Optimize Event.wait()

Antoine Pitrou added the comment: > How about the attached simpler patch? Looks better indeed! I had completely overlooked the possible race condition. -- ___ Python tracker ___

[issue17389] Optimize Event.wait()

Mark Dickinson added the comment: How about the attached simpler patch? -- Added file: http://bugs.python.org/file29364/event_wait_metd.patch ___ Python tracker ___ _

[issue17389] Optimize Event.wait()

Mark Dickinson added the comment: I think there's a race condition in the patched version: 'self._flag' could be set in between if 'if not signaled:' and the 'self._cond.acquire()', and in that case you'll end up waiting for an event that's already occurred. Do you need to recheck 'self._fla

[issue17389] Optimize Event.wait()

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue17389] Optimize Event.wait()

New submission from Antoine Pitrou: It should be possible to optimize threading.Event.wait() to not acquire the condition when the event is already set. Patch attached. Without patch: $ ./python -m timeit -s "import threading; e = threading.Event(); e.set()" "e.wait()" 100 loops, best of