[Python-ideas] Remove GIL with CAS instructions?
Kristján Valur Jónsson
kristjan at ccpgames.com
Wed Oct 21 12:15:52 CEST 2009
> -----Original Message-----
> From: python-ideas-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-ideas-bounces+kristjan=ccpgames.com at python.org] On
> Behalf Of Sturla Molden
> Sent: 20. október 2009 22:13
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Remove GIL with CAS instructions?
> - The GIL has consequences on multicore CPUs that are overlooked:
> switches are usually missed at check intervals. This could be fixed
> without removing the GIL: For example, there could be a wait-queue for
> the GIL; a thread that request the GIL puts itself in the back.
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)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Python-ideas