[Openmcl-devel] Is setf atomic?

[Gary Byers]

RPLACD is basically some fuss on either side of a "store" instruction;
the preceding fuss may have to do with determining whether or not the
first argument is a CONS or not, and the trailing fuss has to do with
keeping track of the case where an old object has been modified to
point to a new one (in the EGC sense.)  If we ignore all that fuss,
the store instruction that actually modifies the CDR of some CONS
cell

   (movq (% new) (@ x8664::cons.cdr (% the-cons))) ; x86-64

is atomic in the sense that you describe: another thread doing

   (cdr the-cons)

at around the time that that store happens will either see the
old CDR or NEW and will not see some weird hybrid.


On Tue, 21 Apr 2009, David L. Rager wrote:

> We all knew this thread would reawaken someday.
>
> Is application of a rplacd atomic (as opposed to the evaluation of a
> replacd's arguments, which are of course non-atomic)?  That is, if I
> replace the cdr of a cons, can I be guaranteed that a separate thread
> reading that cons pair will always see the old cdr or the new cdr and
> not some weird hybrid?
>
> FWIW, I'm on a 64 bit machine.
>
> Thanks~
> David
>
>> If thread A did (setf *var* 42) and thread B did (setf *var* 43)
>> at "about the same time", then the value of *var*  after both
>> threads complete will be either 42 or 43, depending on the
>> whims of the scheduler.  (It will be one or the other, not the
>> old value or some hybrid value.)
>>
>> The only exception to this that I can think of involves storing
>> 64-bit integer values in foreign memory locations on 32-bit
>> hardware; that's done as two "store 32-bit word" operations,
>> and an observer could see that the first word had been stored
>> and the second one hadn't if it looked carefully/quickly enough.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>