Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

Joe Seigh jseigh_01 at xemaps.com
Wed Nov 8 15:40:13 CET 2006

Ross Ridge wrote:
> Ross Ridge schrieb:
>>So give an example where reference counting is unsafe.
> Martin v. Löwis wrote:
>>Nobody claimed that, in that thread. Instead, the claim was
>>"Atomic increment and decrement instructions are not by themselves
>>sufficient to make reference counting safe."
> The problem your describing isn't that reference counting hasn't been
> made safe.  What you and Joe seem to be trying to say is that atomic
> increment and decrement instructions alone don't make accessing shared
> structure members safe.

How you increment and decrement a reference count is an implementation
issue and whether it's correct or not depends on the semantics of the
refcount based pointer.  I.e. what kind of thread safety guarantees
are we ascribing to pointer operations?  Java reference (pointer)
guarantees are not the same as C++ Boost shared_ptr guarantees.  In
Java simple pointer assignment, "a = b;" is always safe no matter what
any other thread may be doing to a and/or b.   With shared_ptr you have
to have a priori knowlege that the refcount for b will never go to
zero during the copy operation.  Usually that implies ownership of b.

To get a better feeling for the latter semantics you should take a look
at C++ String implementations.  A C++ String COW (copy on write) implementation
using atomic inc/dec is as thread-safe as a non-COW String implementation
because in both cases you have to own the strings you access.

About the term "thread-safe".  In Posix it's taken as meaning an operation
on non-shared data isn't affected by other threads.  So non-COW strings
are thread-safe, and COW strings are thread-safe if their internal
refcounting is synchronized properly.   But note that in both cases,
the implemention is transparent to the user.

So as you say, a lot depends on how you access or want to access shared
structure members, e.g. with or without locking. 

Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software. 

More information about the Python-list mailing list