A couple garbage collector questions

[Tim Peters]

[Andrew Kuchling]
> Yes, but you don't know if your C compiler is smart enough to
> generate such code for obj->refcnt++, so usually bits of assembler
> are used.  For example, on Linux there are atomic_inc() and
> atomic_dec() macros in asm/atomic.h.  I doubt there's a way of doing
> this portably.

[Douglas Alan]
> Does the C compiler have to be smart for this to happen atomically?

Very smart, or very stupid.

> Generally wouldn't the normal stupid way be atomic?

No.

> (I'm assuming that "obj" is on the thread's private stack,

Why?  That's never true in Python, for example:  all Python objects are
allocated from the system heap.  It would be an enormous pain to even *try*
to do that differently, since threads aren't part of standard C:  as Andrew
said, there's no portable way to do anything with threads in C.

> and that no thread is going to move the object to a different
> memory location after you've dereferenced the pointer.)

Objects in Python never move after initial allocation, so that's not a
problem.

> Or are there CPU's that will accept an interrupt half-way through
> writing an integer to a memory location?

Sure, depending on the size of the integer.  But Python uses C's "int" type
for refcounts, and offhand I don't know of any platform on which read or
write of a C int is interruptible.  Depending on HW+SW cache coherence
policies, though, you may not be guaranteed that processor A "sees" changes
to a refcount made by processor B in the absence of explicit HW cache
sychronization instructions.

mutation-of-shared-data-needs-exclusion-ly y'rs  - tim