[Patches] [ python-Patches-403892 ] a small optimization for threading.py

[nobody]

Artifact #403892, was updated on 2001-02-19 22:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403892&group_id=5470

Category: library
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Tim Peters
Summary: a small optimization for threading.py

Initial Comment:
This gets rid of some unnecessary calls in the condition variable code of threading.py.  More significantly, it optimizes (what I believe) notify's common case--n == 1.  It's about a 10-15% speedup on the small test program at the end.  If you've questions, post them here.




----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-02-26 11:19

Message:
Logged In: YES 
user_id=31435

Rejected, for reasons explained in the followup 6 days ago.

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-02-20 17:22

Message:
n==1 may or may not be the most common case, but the new code is subject to races so can't be accepted anyway; e.g., thread T1 does a timed .wait(), thread T2 does .notify() and loses its timeslice right before the new self.__waiters[0].release(), T1 gets back just in time for its timed wait to expire, and executes its self.__waiters.remove(waiter), T2 then blows up with an IndexError trying to index into a list that's now empty.

There's a reason .remove() is used everywhere:  self.__waiters is subject to almost arbitrary mutation while .notify() is executing, so you can't safely assume anything about its state is invariant from one line to the next.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403892&group_id=5470