Total Modification Order by Relaxed memory ordering

help
1

Here is the Rust code:

static X: AtomicI32 = AtomicI32::new(0);
fn a()
{
      X.fetch_add(5, Relaxed);
      X.fetch_add(10, Relaxed);
}

This code snippet is taken from the Mara Bos's excellent book.
The X is only modified by a thread.

The book says X only has a 0->5->15 modification order. But I think there might be another modification order possible: 0 -> 10 -> 15. The compiler might reorder the instructions--add the 10 first-- in the function a as Relaxed ordering does not ensure the happens-before relationship. This might happen in extremely loosely ordered hardware architecture.

What do you think?

Thanks,

2

This is explained right before in the book:

While atomic operations using relaxed memory ordering do not provide any happens-before relationship, they do guarantee a total modification order of each individual atomic variable. This means that all modifications of the same atomic variable happen in an order that is the same from the perspective of every single thread.

The relaxed ordering only changes the relationship between X and other variables.

4 Likes
3

Nit: you meant 0->5->15

1 Like
4

thanks.