This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dabeaz
Recipients dabeaz, kristjan.jonsson, loewis, pitrou, ronaldoussoren, ysj.ray
Date 2010-04-21.11:26:45
SpamBayes Score 6.4770167e-09
Marked as misclassified No
Message-id <1271849207.81.0.198486678861.issue8410@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-04-21 11:26:48dabeazsetrecipients: + dabeaz, loewis, ronaldoussoren, pitrou, kristjan.jonsson, ysj.ray
2010-04-21 11:26:47dabeazsetmessageid: <1271849207.81.0.198486678861.issue8410@psf.upfronthosting.co.za>
2010-04-21 11:26:46dabeazlinkissue8410 messages
2010-04-21 11:26:45dabeazcreate