Could proactive multitasking interfere with C ++ 11 release semantics?

Question

Is it possible (theoretically) for a thread to execute acquire on one CPU, and then immediately unload and resume on another CPU for which acquire never executed (and therefore never synchronized in the release, acquire semantics)?

For example, consider the following code that uses C ++ 11 atomicity and release-acquire memory sequencing to perform secure threadless initialization:

 if ( false == _initFlag.load(memory_order_acquire) ) { _foo = ...; // initialize global _bar = ...; // initialize global ... = ...; // initialize more globals _initFlag.store(true, memory_order_release); } // use the initialized values ... 

If _initFlag.load(memory_order_acquire) returns true, then the calling thread will know that the initialized values ​​of _foo , _bar , etc ... are visible (distributed) to the CPU on which it is currently running. But what if the thread is unloaded right after that and moved to another processor? ..

Does the C ++ 11 standard allow the synchronization of a new processor? Are there any implementations or architectures that might be vulnerable to this type of race?

Answer 1

This is possible in order for it to be previously missed and transferred to another CPU after the acquisition, but as far as I know, O / S should ensure that any explicit memory ordering is preserved (this is probably something that is stored in the stream state). Otherwise, there would be very little chance that everything would work reliably in an environment with multiple processors.

I think the standard assumes that it is, based on this.