[issue8410] Fix emulated lock to be 'fair'

[David Beazley]

David Beazley <dave at dabeaz.com> added the comment:

I know that multicore processors are all the rage right now, but one thing that concerns me about this patch is its effect on single-core systems.  If you apply this on a single-CPU, are threads just going to sit there and thrash as they rapidly context switch? (Something that does not occur now).

Also, I've done a few experiments and on a single-core Windows-XP machine, the GIL does not appear to have any kind of fairness to it (as previously claimed here).   Yet, if I run the same experiments on a dual-core PC, the GIL is suddenly fair.  So, somewhere in that lock implementation, it seems to adapt to the environment.  Do we have to try an emulate that behavior in Unix?   If so, how do you do it without it turning into a huge coding mess? 

I'll just mention that the extra context-switching introduced by fair-locking has a rather pronounced effect on performance that should be considered even on multicore.  I posted some benchmarks in Issue 8299 for Linux and OS-X.  In those benchmarks, the introduction of fair GIL locking makes CPU-bound threads run about 2-5 times slower than before on Linux and OS-X.

----------
nosy: +dabeaz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8410>
_______________________________________