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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4