[Python-ideas] [Python-3000] the future of the GIL

[Leonardo Santagada]

Em 09/05/2007, às 04:26, James Y Knight escreveu:

> 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
This seems like a good idea... how about moving this discussion to  
python-ideas?


--
Leonardo Santagada
santagada at gmail.com