Chapter 4 SpinLock: is Acquire/Release synchronization required in the constructor?

[jake-ch-chen]

The content that the question is about

About the constructor of our DIY SpinLock<T>

The question

So I'm wondering if the constructor SpinLock<T>::new is sound by itself, or it takes advantage of the fact that most of the ways one may communicate with other threads already have happens-before relationship semantics built-in.

Currently the constructor snippet of SpinLock is like the following:

impl<T> SpinLock<T> {
    pub const fn new(value: T) -> Self {
        Self {
            locked: AtomicBool::new(false),
            value: UnsafeCell::new(value),
        }
    }

    …
}

I'm wondering why we don't need something like this, considering there may be some move of T happening during the call?

impl<T> SpinLock<T> {
    pub const fn new(value: T) -> Self {
        let ret = Self {
            locked: AtomicBool::new(true),
            value: UnsafeCell::new(value),
        };
        ret.locked.store(false, atomic::Ordering::Release);
        ret
    }
}

Is it because for any &SpinLock<T> to be available in other threads, some sort of thread spawn or channels are ultimately required, and since the thread::spawn/Sender::send mostly likely already provide the required happens-before semantics, we don't really need to (re-)implement the happens-before relationship in our SpinLock<T>::new again?