Re: Thread-safe assignments

On Wed, 07 Nov 2007 12:57:14 +0100, Pascal Costanza <pc@xxxxxxxxx>
wrote:

Hi,

I realize that my recent question about thread-safe caches was pretty
ambiguous. So here is a question narrowed down to something simpler,
which is hopefully more straightforward to answer.

Assume there is a global variable *var*, for example defined like this:

(cl:defvar *var* 42)

Assume there is exactly one thread forever executing the following loop:

(cl:loop
(cl:setf *var* 42)
(cl:setf *var* 84))

Furthermore, assume that other threads either don't touch *var* at all,
or only read from it.

Is it safe to assume that the reading threads will only ever read the
values 42 or 84 from *var*, or should one take into account that every
now and then, *var* may contain garbage (i.e., a bit pattern that
consists partly of the bits of 42, and partly of the bits of 84)?

To generalize, are there datatypes for which it is not safe to assume
that variable assignments are thread-safe in that sense?

What about plain references?

[Since ANSI Common Lisp doesn't say anything about multithreading, this
is by definition implementation-dependent, but nevertheless how
sufficiently safe is it to assume thread-safe variable assignments?]


Thanks for any comments,
Pascal

You'll never perceive a partially updated single word value - all
single word reads and writes are atomic. The only possibility would
be a delay in propagating the new value on a separate memory
multi-processor - shared memory multi-processors use cache snooping to
keep their view of memory consistent.

Multiple word updates are not safe without synchronization.

Keep in mind though that fixnum updates aren't truly an atomic
operation in Lisp. Tagging the value and writing it to memory takes a
couple of instructions - another thread could potentially sneak in and
read the old value between the time setf is called and the time the
tagged value is actually written to memory. This is unlikely to
matter to you, but I mention it for completeness.

A problem you may encounter is that compiler optimizations might
prevent another thread from seeing the updates even on a single CPU.
Unless the compiler knows the object may be modified by foreign code,
it may cache the value in a register and ignore updates in memory.
The C term for this is a "volatile" variable.

I don't have much multi-thread experience in Lisp - but I would expect
that because many common objects are actually multi-word structures,
that multi-thread implementations either use critical sections
internally or punt synchronization to the programmer. I would say
some quality time with the compiler manual is in order.

George
--
for email reply remove "/" from address
.

Relevant Pages

  • Re: When is "volatile" used instead of "lock" ?
    ... with respect to the memory model. ... Where else is it violating the 335 memory ... can still write thread-safe code. ... IAsyncResult result = BeginBackgroundOperation(ref value1, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Thread-safe assignments
    ... If it isn't implemented thread-safe, ... When just incrementing an integer you are normally getting three machine instructions: ... whatever was in memory at the time. ... register should be atomic for simple values at least. ...
    (comp.lang.lisp)
  • RE: Are Application collection and Page.Cache thread safe?
    ... means you can freely store and access objects in Cache entry without ... thread-safe is important if you'll take care of the concurrent accessing in ... highly concurrent web sites?" ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Newbie Question
    ... as you're a "newbie" I thought ... you might not be awarae of the Application Cache, ... the ApplicationState, because it is thread-safe. ... The Cache also has the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Thread-safe caches
    ... i think plists are thread-safe when setq, rplaca and rplacd are atomic, which i believe is true. ... concurrent incompatible updates possible and what to do in this case. ... Cache entries are never deleted. ...
    (comp.lang.lisp)