[Python-3000] the future of the GIL

[James Y Knight]

On May 7, 2007, at 1:58 PM, Guido van Rossum wrote:
> As C doesn't have an atomic increment nor an atomic
> decrement-and-test, the INCREF and DECREF macros sprinkled throughout
> the code (many thousands of them) must be protected by some lock.

I've been intently ignoring the rest of the thread (and will continue  
to do so), but, to respond to this one particular point...

This just isn't true. Python can do an atomic increment in a fast  
platform specific way. It need not restrict itself to what's  
available in C. (after all, *threads* aren't available in C....)

Two implementations of note:

1) gcc 4.1 has atomic operation builtins:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic- 
Builtins.html#Atomic-Builtins

2) There's a pretty damn portable library which provides these  
functions for what looks to me like pretty much all CPUs anyone would  
use, under Linux, Windows, HP/UX, Solaris, and OSX, and has a  
fallback to using pthreads mutexes:

http://www.hpl.hp.com/research/linux/atomic_ops/index.php4
http://packages.debian.org/stable/libdevel/libatomic-ops-dev


It's quite possible the overhead of GIL-less INCREF/DECREF is still  
too high even with atomic increment/decrement primitives, but AFAICT  
nobody has actually tried it. So saying GIL-less operation for sure  
has too high of an overhead unless the refcounting GC is replaced  
seems a bit premature.

James