[Openmcl-devel] Is setf atomic?

[Gary Byers]

Sorry; I was writing a longer screed/polemic and missed this.

If we assume that no other thread is executing any SETFs on VAR
when we are, then the value of VAR will either be its old value
or 42 at all times; it will not contain some bits/partial words
from the old value and some from the new value, and (thanks
to the OS and hardware) this would be true even if the value
cell crossed page or cache line boundaries.

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.

Storing part of a tagged lisp word where a full tagged lisp word was
expected (if there was some reason to do this) would make the
GC very upset; this could be an issue if we were trying to
emulate a 64-bit implementation on 32-bit hardware and could
still GC on any native instruction boundary.

On Tue, 6 Nov 2007, Pascal Costanza wrote:

>
> On 6 Nov 2007, at 21:59, Andrew Shalit wrote:
>
>> What would it mean for (setf var 42) to be thread-safe or not thread safe?
>> 
>> I can understand what this might mean for
>> 
>> (setf var (do-something-complex))  ;; lots of stuff can happen during the 
>> calculation of do-something-complex
>>                                                              ;;and between 
>> the time that value is calculated and the variable is assigned
>> 
>> and I can understand what it could mean for
>> 
>> (progn
>> (setf var 42)
>> var)  ;;var might not be 42 at this point
>> 
>> or
>> 
>> (progn
>> (setf var 42)
>> (setf foo var))  ;; foo could be set to pretty much anything
>> 
>> But what would it mean for (setf var 42) in isolation not to be thread 
>> safe?
>
> 42 could be stored in a 64-bit place, and the store operation could be split 
> up in two 32-bit store operations. Thus, it could happen that other threads 
> see just garbage when they happen to do a read access in between.
>
> For example, that's a case that is documented for Java's memory model, see 
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7
>
>
> Pascal
>
> -- 
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>