[Python-3000] the future of the GIL (original) (raw)

James Y Knight foom at fuhm.net
Wed May 9 09:26:06 CEST 2007

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

More information about the Python-3000 mailing list