> You should definitely open a bug entry in http://bugs.python.org. There, post > your patch, some explanations and preferably a quick way (e.g. a simple script) > of reproducing the speedups (without having to install a third-party library or > extension, that is). I'll get started on that. I'm assuming I should generate a patch from the trunk (2.7)? The file doesn't look different, but I want to make sure I get it from the right place. > I wonder if the patch could be structured as a conditional compilation? You > know how many different spots are touched, and how many lines per spot. > > If it could be, then theoretically it could be released and people could do > lots of comparative stress testing with different workloads. That would be easy to do, because I am just replacing the *NonRecursiveMutex functions. > What about fairness? I don't know off-hand whether the GIL is > fair, or whether critical sections are fair, but it needs to be > considered. If you define fairness in this context as not starving other threads while consuming resources, that is built into the interpreter via sys.setcheckinterval() and also anywhere the GIL is released for I/O. What might be interesting is to see if releasing a critical section and immediately re-acquiring it every _Py_CheckInterval bytecode operations behaves in a similar manner (see ceval.c, line 869). My best guess right now is that it will behave as expected when not using the spin-based critical section. AFAIK, the kernel processes waiters in a FIFO manner without regard to priority. Because a guarantee of mutual exclusion is absolutely necessary, it's up to applications to provide fairness. Python does a decent job of this. - Phillip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4