[Python-Dev] [Python-ideas] Remove GIL with CAS instructions? (original) (raw)
John Arbash Meinel john at arbash-meinel.com
Wed Oct 21 17:27:12 CEST 2009
- Previous message: [Python-Dev] GIL behaviour under Windows
- Next message: [Python-Dev] [Python-ideas] Remove GIL with CAS instructions?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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: http://fonp.blogspot.com/2007/10/fairness-in-win32-lock-objects.html 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) Cheers, Kristján
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 Express)
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 thread.
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 machine.
John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrfKFAACgkQJdeBCYSNAANbuQCgudU0IChylofTwvUk/JglChBd 9gsAoIJHj63/CagKpduUsd68HV8pP3QX =CuUj -----END PGP SIGNATURE-----
- Previous message: [Python-Dev] GIL behaviour under Windows
- Next message: [Python-Dev] [Python-ideas] Remove GIL with CAS instructions?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]