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

[Ross Ridge]

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."

So give an example of where atomic increment and decrement instructions
are not by themselves sufficent to make reference counting safe.

> I did give an example, in <4550cc64$0$3462$9b622d9e at news.freenet.de>.
> Even though f_name is reference-counted, it might happen that you get a
> dangling pointer.

Your example is of how access to the "f_name" member is unsafe, not of
how reference counting being unsafe.  The same sort of race condition
can without reference counting being involved at all.  Consider the
"f_fp" member: if one thread tries to use "printf()" on it while
another thread calls "fclose()", then you can have same problem.  The
race condition here doesn't happen because reference counting hasn't
been made safe, nor does it happen because stdio isn't thread-safe.  It
happens because accessing "f_fp" (without the GIL) is unsafe.

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.
                                       Ross Ridge