A couple garbage collector questions
Tim Peters
tim.one at home.com
Wed Apr 4 17:21:53 EDT 2001
[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
More information about the Python-list
mailing list