[Python-Dev] [Python-ideas] Remove GIL with CAS instructions?
John Arbash Meinel
john at arbash-meinel.com
Wed Oct 21 17:27:12 CEST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Kristján Valur Jónsson wrote:
> This depends entirely on the platform and primitives used to implement the GIL.
> I'm interested in windows. There, I found this article:
> So, you may be on to something. Perhaps a simple C test is in order then?
> I did that. I found, on my dual-core vista machine, that running "release", that both Mutexes and CriticalSections behaved as you describe, with no "fairness". Using a "semaphore" seems to retain fairness, however.
> "fairness" was retained in debug builds too, strangely enough.
> Now, Python uses none of these. On windows, it uses an "Event" object coupled with an atomically updated counter. This also behaves fairly.
> The test application is attached.
> I think that you ought to sustantiate your claims better, maybe with a specific platform and using some test like the above.
> On the other hand, it shows that we must be careful what we use. There has been some talk of using CriticalSections for the GIL on windows. This test ought to show the danger of that. The GIL is different than a regular lock. It is a reverse-lock, really, and therefore may need to be implemented in its own special way, if we want very fast mutexes for the rest of the system (cc to python-dev)
I can compile and run this, but I'm not sure I know how to interpret the
results. If I understand it correctly, then everything but "Critical
Sections" are fair on my Windows Vista machine.
To run, I changed the line "#define EVENT" to EVENT, MUTEX, SEMAPHORE
and CRIT. I then built and ran in "Release" environment (using VS 2008
For all but CRIT, I saw things like:
thread 5532 reclaims GIL
thread 5532 working 51234 units
thread 5532 worked 51234 units: 1312435761
thread 5532 flashing GIL
thread 5876 reclaims GIL
thread 5876 working 51234 units
thread 5876 worked 51234 units: 1312435761
thread 5876 flashing GIL
Where there would be 4 lines for one thread, then 4 lines for the other
for CRIT, I saw something more like 50 lines for one thread, and then 50
lines for the other thread.
This is Vista Home Basic, and VS 2008 Express Edition, with a 2-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Python-Dev