A couple garbage collector questions

[Aahz Maruch]

In article <lcg0foxvu6.fsf at gaffa.mit.edu>,
Douglas Alan  <nessus at mit.edu> wrote:
>Andrew Kuchling <akuchlin at mems-exchange.org> writes:
>> Douglas Alan <nessus at mit.edu> writes:
>>>
>>> Why do you need to lock on increment/decrement?  Isn't incrementing or
>>> decrementing an integer an atomic operation on most CPU's?
>>
>> 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.
>
>Does the C compiler have to be smart for this to happen atomically?
>Generally wouldn't the normal stupid way be atomic?  (I'm assuming
>that "obj" is on the thread's private stack, and that no thread is
>going to move the object to a different memory location after you've
>dereferenced the pointer.)  Or are there CPU's that will accept an
>interrupt half-way through writing an integer to a memory location?

IIUC, your parenthetical assumption (that obj is private) is *NOT*
correct and is precisely the reason for the Global Interpreter Lock.
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

"The only problem with Microsoft is they just have no taste." --Steve Jobs