A couple garbage collector questions

[Brian Quinlan]

You shouldn't count on architectural details to guarantee thread safety.
There are architectures out there that require multiple instructions to
perform an add. The PowerPC series (or at least the MPC601), for example,
requires that you:

1) load refcnt to a register
2) increment the register
3) save the register back to refcnt

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Douglas Alan
Sent: Wednesday, April 04, 2001 1:18 PM
To: python-list at python.org
Subject: Re: A couple garbage collector questions


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?

|>oug
--
http://mail.python.org/mailman/listinfo/python-list