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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
