I've often thought of this. The problem is that the GIL uses the regular python "lock" which has to be non-recursive, since it is used for synchronization operations other than mutual exclusion, e.g. one thread going to sleep, and another waking it up. Now, we could easily create another class of locks, a python "mutex" or a "critical section" even, which is allowed (but not required) to be recursive. On other platforms, this could fall back to being the good old lock. Requiring it to be recursive would mean that we would need implementations for all platforms. Which is possible, I suppose, building on the old python lock...
For the GIL, we would then use a python "mutex" or "critical section" whichever you prefer. Note that for the GIL, if you use a CriticalSection object, you should initialize its "spincount" to zero, because the GIL is almost always in contention. That is, if you don't get the GIL right away, you won't for a while. I don't know what kernel primitive the Critical Section uses, but if it uses an Event object or something similar, we are in the same soup, so to say, because the CriticalSection's spinlocking feature buys us nothing. K -----Original Message----- From: python-dev-bounces+kristjan=ccpgames....@python.org [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of Phillip Sitbon Sent: 26. maí 2009 19:49 To: python-dev@python.org Subject: [Python-Dev] Making the GIL faster & lighter on Windows Hi everyone, I'm new to the list but I've been embedding Python and working very closely with the core sources for many years now. I discovered Python a long time ago when I needed to embed a scripting language and found the PHP sources... unreadable ;) Anyway, I'd like to ask something that may have been asked already, so I apologize if this has been covered. Instead of removing the GIL, has anyone thought of making it more lightweight? The current situation for Windows is that the single-thread case is decently fast (via interlocked operations), but it drops to using an event object in the case of contention. (see thread_nt.h) _______________________________________________ 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
