Movatterモバイル変換


[0]ホーム

URL:


A couple garbage collector questions

Brian QuinlanBrianQ at ActiveState.com
Wed Apr 4 16:49:08 EDT 2001


You shouldn't count on architectural details to guarantee thread safety.There are architectures out there that require multiple instructions toperform an add. The PowerPC series (or at least the MPC601), for example,requires that you:1) load refcnt to a register2) increment the register3) 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 AlanSent: Wednesday, April 04, 2001 1:18 PMTo:python-list at python.orgSubject: Re: A couple garbage collector questionsAndrew 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 assumingthat "obj" is on the thread's private stack, and that no thread isgoing to move the object to a different memory location after you'vedereferenced the pointer.)  Or are there CPU's that will accept aninterrupt half-way through writing an integer to a memory location?|>oug--http://mail.python.org/mailman/listinfo/python-list


More information about the Python-listmailing list

[8]ページ先頭

©2009-2025 Movatter.jp