Memory ordering questions on given example?

I have questions about memory reorderings in this code

fn do_something_under_lock(
    is_locked: &AtomicBool,
    some_atomic_counter_1: &AtomicUsize,
    some_atomic_counter_2: &AtomicUsize,
) {
    read_and_write_non_atomic_memory_1_before_lock();
    read_and_write_non_atomic_memory_2_before_lock();
    some_atomic_counter_1.fetch_add(1, Ordering::Relaxed);
    some_atomic_counter_2.fetch_add(1, Ordering::Relaxed);

    let mut succeeded_acquire;
    loop {
        succeeded_acquire = is_locked
            .compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed)
            .is_ok();

        if succeeded_acquire {
            read_and_write_non_atomic_memory_1_inside_lock();
            some_atomic_counter_1.fetch_add(2, Ordering::Relaxed);

            is_locked.store(false, Ordering::Release);
            break;
        }
    }

    read_and_write_non_atomic_memory_1_after_lock();
    read_and_write_non_atomic_memory_2_after_lock();
    some_atomic_counter_1.fetch_add(3, Ordering::Relaxed);
    some_atomic_counter_2.fetch_add(3, Ordering::Relaxed);
}

<hr>

Here I will be giving a list of questions and answers based on my understanding, but I would like confirmation if I am correct:

1. Can

   read_and_write_non_atomic_memory_1_before_lock();
   

   be reordered to place before do_something_under_lock call(like if it was inlined)?
   > Yes, up until the point where we have atomic Acquire(because Acquire prevents reordering to places before itself) or non-atomic operation on same memory(because it would break single threaded logic)

2. Can

   read_and_write_non_atomic_memory_1_before_lock();
   

   be reordered to place after atomic Acquire?
   > Yes, because atomic Acquire doesn't prevent compiler from reordering to places after it

3. Can

   read_and_write_non_atomic_memory_1_before_lock();
   

   be reordered to place after

   read_and_write_non_atomic_memory_1_inside_lock();
   

   ?
   > No, because these operations affect same memory, so they should happen in same order, as they were met in code, because otherwise logic of single threaded execution may break

4. Can

   read_and_write_non_atomic_memory_1_inside_lock();
   

   be reordered to place after atomic Release?
   > No, because atomic Release prevents it

5. Can

   read_and_write_non_atomic_memory_1_after_lock();
   

   be reordered to place before Release?
   > Yes, because atomic Release doesn't prevent reordering to places before itself

6. Can

   read_and_write_non_atomic_memory_1_after_lock();
   

   be reordered to place before

   read_and_write_non_atomic_memory_1_inside_lock();
   

   ?
   > No, because these operations affect same memory, so they should happen in same order, as they were met in code, because otherwise logic of single threaded execution may break

7. Can

   read_and_write_non_atomic_memory_2_before_lock();
   

   be reordered to place before do_something_under_lock call(like if it was inlined)?
   > Yes, up until the point where we have atomic Acquire(because Acquire prevents reordering to places before itself) or non-atomic operation on same memory(because it would break single threaded logic)

8. Can

   read_and_write_non_atomic_memory_2_before_lock();
   

   be reordered to place before

   read_and_write_non_atomic_memory_1_before_lock();
   

   ?
   > Yes, because these operations don't affect same memory and don't have atomic Acquire or Release between them

9. Can

   read_and_write_non_atomic_memory_2_before_lock();
   

   be reordered to place after atomic Acquire?
   > Yes, because atomic Acquire doesn't prevent compiler from reordering to places after it

10. Can

    read_and_write_non_atomic_memory_2_before_lock();
    

    be reordered to place after atomic Release?
    > No, because atomic Release prevents it

11. Can

    read_and_write_non_atomic_memory_2_after_lock();
    

    be reordered to place before Release?
    > Yes, because atomic Release doesn't prevent reordering to places before itself

12. Can

    read_and_write_non_atomic_memory_2_after_lock();
    

    be reordered to place before Acquire?
    > No, because atomic Acquire prevents reordering to places before itself

13. Can

    some_atomic_counter_1.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place before do_something_under_lock call(like if it was inlined)?
    > Yes, up until the point where we have atomic Acquire(because Acquire prevents reordering to places before itself) or operation on same atomic memory(because it would break single threaded logic)

14. Can

    some_atomic_counter_1.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place after atomic Acquire?
    > Yes, because atomic Acquire doesn't prevent compiler from reordering to places after itself

15. Can

    some_atomic_counter_1.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place after

    some_atomic_counter_1.fetch_add(2, Ordering::Relaxed);
    

    ?
    > No, because these operations affect same memory, so they should happen in same order, as they were met in code, because otherwise logic of single threaded execution may break

16. Can

    some_atomic_counter_1.fetch_add(2, Ordering::Relaxed);
    

    be reordered to place after atomic Release?
    > No, because atomic Release prevents it

17. Can

    some_atomic_counter_1.fetch_add(3, Ordering::Relaxed);
    

    be reordered to place before Release?
    > Yes, because atomic Release doesn't prevent reordering to places before itself

18. Can

    some_atomic_counter_1.fetch_add(3, Ordering::Relaxed);
    

    be reordered to place before

    some_atomic_counter_1.fetch_add(2, Ordering::Relaxed);
    

    ?
    > No, because these operations affect same memory, so they should happen in same order, as they were met in code, because otherwise logic of single threaded execution may break

19. Can

    some_atomic_counter_2.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place before do_something_under_lock call(like if it was inlined)?
    > Yes, up until the point where we have atomic Acquire(because Acquire prevents reordering to places before itself) or operation on same atomic memory(because it would break single threaded logic)

20. Can

    some_atomic_counter_2.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place before

    some_atomic_counter_1.fetch_add(1, Ordering::Relaxed);
    

    ?
    > Yes, because these operations don't affect same memory and don't have atomic Acquire or Release between them

21. Can

    some_atomic_counter_2.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place after atomic Acquire?
    > Yes, because atomic Acquire doesn't prevent compiler from reordering to places after itself

22. Can

    some_atomic_counter_2.fetch_add(1, Ordering::Relaxed);
    

    be reordered to place after atomic Release?
    > No, because atomic Release prevents it

23. Can

    some_atomic_counter_2.fetch_add(3, Ordering::Relaxed);
    

    be reordered to place before Release?
    > Yes, because atomic Release doesn't prevent reordering to places before itself

24. Can

    some_atomic_counter_2.fetch_add(3, Ordering::Relaxed);
    

    be reordered to place before Acquire?
    > No, because atomic Acquire prevents reordering to places before itself

25. What would happen if we changed Acquire to Relaxed in line

    succeeded_acquire = is_locked
        .compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed)
        .is_ok();
    

    ?
    > Compiler wouldn't tell CPU to load to local core cache actual memory changes from global memory and would work on potentially old memory, causing race in read_and_write_non_atomic_memory_1_inside_lock();

26. What would happen if we changed Release to Relaxed in line

    is_locked.store(false, Ordering::Release);
    

    ?
    > Compiler wouldn't tell CPU to push local memory changes from local core cache to global memory and other cores would work on potentially old memory, causing race in read_and_write_non_atomic_memory_1_inside_lock();

There is a subtlety in #3 and #6, involving multiple accesses to the same non-atomic object.

First, apparently Rust does not yet have a defined memory model, so it may be that these questions cannot be answered with complete authority. However, my understanding is that for all intents and purposes, it matches the C++ memory model, which is not defined in terms of "reordering" at all, but in terms of abstract ordering constraints that allow you to deduce whether certain program behaviors are possible or not. So in that sense, asking whether one access can be reordered with another is not formally a well-defined question.

Now, in #3 and #6, what is true is that within the current thread, the accesses to the various non_atomic_memory objects will be observed as if in program order. For example, read_and_write_non_atomic_memory_1_inside_lock() will read the value that was written by read_and_write_non_atomic_memory_1_before_lock(). In that sense, they cannot be reordered.

However, from the point of view of another thread, they can be reordered, or worse. In fact, if any other thread is observing this variable concurrently with these accesses, the program has a data race and its entire behavior is undefined. (And in Rust, it should actually be impossible for any other thread to do so, unless there is unsafe code in play to defeat the borrow checker.) So the compiler is under no obligation to generate actual memory loads and stores matching the accesses that your read_and_write() functions do, if it can get the same effect within the current thread in some other way. For instance, the value written by the before_lock() write might never actually be stored to memory, but instead cached in a register which is then used by the inside_lock() read. Or they could be scrambled up in some arbitrarily complicated fashion.

The value in memory doesn't have to be "correct" until such time as another thread could access the variable without causing a data race, which doesn't happen at any point within the code you posted.