-----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----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com