ECAM-334 says:

12.5 Atomicity of variable references
Reads and writes of the following data types shall be atomic: bool,
char, byte, sbyte, short, ushort,
uint, int, float, and reference types. In addition, reads and writes of
enum types with an underlying type
in the previous list shall also be atomic. Reads and writes of other
types, including long, ulong, double,
and decimal, as well as user-defined types, need not be atomic. Aside
from the library functions designed
for that purpose, there is no guarantee of atomic read-modify-write,
such as in the case of increment or
decrement.

and I read the "and reference types" as if reading and writing a
reference is atomic.

Arne

No.

Yes, but that's not the same thing.

Atomicity guarantees that you won't see an invalid value - but it
doesn't mean you'll see the *latest* value. Due to JIT optimisations
etc, if you don't have a memory barrier there's no guarantee you'll
see any changes to the data.

Basically, if shared data can change you either need a memory barrier
or a lock (the latter of which provides a memory barrier) in order to
make sure you see the changed value.

Jon

A related question: is there somethng like AtomicBoolean etc. also
available in C# standard libraries?

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/package-summ
ary.html

This is A small toolkit of classes that support lock-free thread-safe
programming on single variables.

I have recently found that these Atomic<Datatype> classes are really
useful in multithreaded applications, and since I am still a novice to
C# maybe somebody knows if they exist...

Best Regards

As others have pointed out, these are two different questions, and don't
have the same meaning.

In the more loose memory architectures (ruling out the x86,
essentially), there are publishing issues with assigning references that
are read from a different thread. If the hardware reorders reads or
writes, then it's possible to publish a value (i.e. replace a reference
in a structure visible to other threads) that isn't fully created.

For example, in the following program it's possible that "Oh dear!" will
get printed to the console, if the hardware reorders reads and writes:

---8<---
using System;
using System.IO;
using System.Threading;

class App
{
   static Referent Reference;
   
   class Referent
   {
       public int Field;
   }
   
   static void Main()
   {
       Thread setter = new Thread(() =>
       {
           for (;;)
           {
               Referent r = new Referent();
               r.Field = 42;
               Reference = r;
           }
       });
       setter.Start();
       
       for (;;)
       {
           Referent r = Reference;
           if (r != null && r.Field == 0)
           {
               Console.WriteLine("Oh dear!");
               break;
           }
       }
       Environment.Exit(0);
   }
}
--->8---

It does, however, appear to work perfectly fine as is on x86. x86
doesn't seem to do the kinds of reorderings that can cause problems
here.

-- Barry