Atomic operations

[Jon Harrop]

Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a reference an
atomic operation?

I have been assuming that all writes of <=1 word of data are atomic. Is this
actually documented anywhere?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Harrop wrote:

Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a reference an
atomic operation?

I have been assuming that all writes of <=1 word of data are atomic. Is this
actually documented anywhere?

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

[Jon Harrop]

Jon Skeet [C# MVP] wrote:

On Apr 19, 6:34*am, Jon Harrop <[e-mail]:

>Can read locks on a data structure be removed safely when updates are
limited to replacing a reference?

No.

>In other words, is setting a reference an atomic operation?

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.

I don't need to see the latest value.

If thread X is writing then I don't mind thread Y reading either the old or
new value provided it is read correctly.

Am I correct in thinking that replacing a reference to object A with a
reference to object B in thread X will yield a valid A or B in thread Y?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

[Jon Harrop]

Arne Vajhøj wrote:

Jon Harrop wrote:

>Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a reference
an atomic operation?

I have been assuming that all writes of <=1 word of data are atomic. Is
this actually documented anywhere?

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.

Sounds good to me. :-)

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

[Peter Duniho]

On Sat, 19 Apr 2008 08:59:22 -0700, Jon Harrop <jo*@ffconsultancy.com>
wrote:

[...]
Am I correct in thinking that replacing a reference to object A with a
reference to object B in thread X will yield a valid A or B in thread Y?

I suppose that depends on whether the reference ever referred to something
other than A or B. If it did, then you could at least in theory get yet
another value other than A or B (i.e. whatever the value was before it was
A). I think in practice the likelihood is low, but that's no way to prove
your codeis correct. :)

IMHO, even if you don't care about the age of the value, you should still
use "volatile" with the variable. You'll still have a race condition (but
presumably not a harmful one), but you'll at least be assured that if the
value is out-of-date, it's only because some other thread hasn't gotten to
update it yet.

Without "volatile", compiler optimizations can cause worse problems, such
as values that are no longer even relevant.

Pete

[Michael Justin]

Jon Harrop wrote:

Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a reference an
atomic operation?

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

http://java.sun.com/j2se/1.5.0/docs/...e-summary.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<Datatypeclasses are really
useful in multithreaded applications, and since I am still a novice to
C# maybe somebody knows if they exist...

Best Regards
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphiâ„¢ and for the Javaâ„¢ platform
http://www.mikejustin.com - http://www.betabeans.de

[Jon Skeet [C# MVP]]

On Apr 19, 8:59*am, Jon Harrop <[e-mail]:

Atomicity guarantees that you won't see an invalid value - but it
doesn't mean you'll see the *latest* value.

I don't need to see the latest value.

Okay, then that's a different idea of "safely" than I think most
people would have :)

(I guess it is safe but not usually desirable.)

If thread X is writing then I don't mind thread Y reading either the old or
new value provided it is read correctly.

Am I correct in thinking that replacing a reference to object A with a
reference to object B in thread X will yield a valid A or B in thread Y?

Yes. So long as you don't mind if you never, ever, ever see the
reference to object B in thread Y, you're fine.

Jon

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Harrop wrote:

Am I correct in thinking that replacing a reference to object A with a
reference to object B in thread X will yield a valid A or B in thread Y?

That is what the language standard says.

Arne

[Jeroen Mostert]

Michael Justin wrote:

Jon Harrop wrote:

>Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a
reference an
atomic operation?

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

http://java.sun.com/j2se/1.5.0/docs/...e-summary.html

Try the Interlocked class. It should actually be possible to write classes
like AtomicBoolean in C# using that.

--
J.
http://symbolsprose.blogspot.com

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

On Apr 19, 8:59 am, Jon Harrop <[e-mail]:

>>Atomicity guarantees that you won't see an invalid value - but it
doesn't mean you'll see the *latest* value.

I don't need to see the latest value.

Okay, then that's a different idea of "safely" than I think most
people would have :)

(I guess it is safe but not usually desirable.)

If the threads are really unsynchronized that is normal (the
two scenarios X not having set the ref yet and X having
set the ref but Y can not see it yet are somewhat equivalent).

>If thread X is writing then I don't mind thread Y reading either the old or
new value provided it is read correctly.

Am I correct in thinking that replacing a reference to object A with a
reference to object B in thread X will yield a valid A or B in thread Y?

Yes. So long as you don't mind if you never, ever, ever see the
reference to object B in thread Y, you're fine.

Is this problem:
- something that is undefined in the C#/CLI memory model but happens
to work on x86 and x86-64 but could fail on IA-64 and PPC
or:
- something that can fail on x86 and x86-64 as well
?

(I think I have read that the x86/x86-64 memory model are not
so aggressive)

Arne

[Jon Skeet [C# MVP]]

On Apr 19, 10:08 am, Arne Vajhøj <[e-mail]:

Yes. So long as you don't mind if you never, ever, ever see the
reference to object B in thread Y, you're fine.

Is this problem:
- something that is undefined in the C#/CLI memory model but happens
to work on x86 and x86-64 but could fail on IA-64 and PPC
or:
- something that can fail on x86 and x86-64 as well
?

(I think I have read that the x86/x86-64 memory model are not
so aggressive)

I don't know about references, but I've certainly seen static boolean
variables being changed in one thread but that change never being seen
in a different thread, even on a single-core x86 machine. I believe
the other thread had effectively enregistered the variable, and saw no
reason to update the registers.

Admittedly as soon as there are non-inlined method calls involved, the
problem tends to go away IIRC - because the JIT can't know that the
method call won't involve a memory barrier, making the effective
reordering invalid - but it's something to be aware of anyway.

Jon

[Barry Kelly]

Jon Harrop wrote:

Can read locks on a data structure be removed safely when updates are
limited to replacing a reference? In other words, is setting a reference an
atomic operation?

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

--
http://barrkel.blogspot.com/