Question Body:

I have a piece of Rust code where two threads access and modify the same static usize using raw mutable pointers. The operations performed on the value are bitwise and non-atomic, but the logic ensures only one thread writes to the memory location at a time, based on a conditional check.

Here’s the code:

use std::time::Duration;

#[derive(Clone, Copy)]
struct StaticNumber(*mut usize);
unsafe impl Send for StaticNumber {}

fn main() {
    let number = StaticNumber(Box::leak(Box::new(usize::MAX)) as *mut usize);

    let t1 = std::thread::spawn(move || thread1(number));
    let t2 = std::thread::spawn(move || thread2(number));

    let _ = t1.join();
    let _ = t2.join();
}

fn thread1(number: StaticNumber) {
    loop {
        if unsafe { *number.0 } & 1 == 0 {
            unsafe { *number.0 |= 1 };
        } else {
            std::thread::sleep(Duration::from_millis(1));
        }
    }
}

fn thread2(number: StaticNumber) {
    loop {
        if unsafe { *number.0 } & 1 == 1 {
            unsafe { *number.0 &= usize::MAX << 1 };
        } else {
            std::thread::sleep(Duration::from_millis(1));
        }
    }
}

The core idea is as follows:

• Each thread reads the least significant bit (LSB) of the usize value.
• Based on the LSB, one thread sets it to 1, while the other resets it to 0.
• The application logic ensures that the state read by each thread is eventually consistent, as both threads check the LSB before attempting to modify the value.

However, the code uses raw pointers to access the same memory concurrently, which is often said to lead to undefined behavior (UB) in Rust due to potential issues like:

• Non-atomicity of operations (read-modify-write could interleave unpredictably).
• Compiler and CPU optimizations (e.g., instruction reordering, stale cache reads).
• Violations of Rust’s aliasing rules for mutable references.

The Question:

Given the logic and the context:

1. Is this actually undefined behavior according to Rust’s memory model?
2. Does the presence of non-atomic bitwise operations introduce risks such as memory corruption, crashes, or other undesirable behavior despite the conditional checks in place?
3. Could compiler or CPU optimizations (e.g., reordering, stale reads, speculative execution) cause this logic to break, even if the program seemingly guarantees mutual exclusivity in updates?

While I understand that using atomics would be the correct way to handle this scenario, I am curious if this specific code, with its eventual consistency model, is truly UB in the technical sense. Would love an explanation based on Rust’s aliasing rules, compiler optimizations, and the underlying hardware behavior.