14 hours ago, Shaarigan said:

I use that behind the scenes as platform and architecture independent std::atomic replacement for something like spin locking in our professional engine

#if defined(__GNUC__)
#define SpinLock(__lock) { while (sync_lock_test_and_set(&(__lock), 1)) while (lock) {} }
#define SpinUnlock(__lock) { __sync_lock_release(&(__lock)); }
#elif defined(WINDOWS)
#define SpinLock(__lock) { while (InterlockedExchange(&(__lock), 1)) while (__lock) {} }
#define SpinUnlock(__lock) { InterlockedExchange(&(__lock), 0); }
#endif

But anybody should stay aware of exotic platforms that implement their own interlocked functions like PSSDK or Switch SDK does

While we're on the topic, Intel recommends that you put a _mm_pause or YieldProcessor (MSVC) call inside the body of any spin loop, which emits a special kind of NOP instruction. The CPU will recognize this pattern, de-pipeline the decoded loop instructions, switch to the HW hyper-thread if the loop keeps spinning, and reduce power consumption until the loop exits  

For everyone else: using spin-loops is in general a pretty bad idea for performance. Your compiler's default locks (e.g. a critical section on Win32/MSVC) will use a tried, tested and well tuned spin-lock and then progressively fall back to more heavyweight algorithms if it spins for "too long".

5 minutes ago, maxest said:

Please correct me if I'm drawing bad conclusions from it but I think that in a case where thread 1 is only writing and thread 2 is only reading then the only purpose of mutex lock/unlock is to prevent compiler from reordering instructions and making wrong optimizations. Is that correct? Because precisely what I'm doing with my bool variable is to mark the moment when some work has been done. So I wouldn't really want my compiler to set that variable to true *before* the actual work is done.

Yep. But not JUST the compiler. Some CPUs will reorder your instructions at runtime (e.g. Intel), some will reorder memory reads and writes (Intel in certain situations), some will do both! Low level ASM/binary instructions are actually basically a high level byte code these days, and modern CPUs will take that instruction stream and dynamically compile it into another set of internal instructions... Optimising on the fly

So, you do some work, make sure that the work is actually completed and visible to other CPU cores, then write the boolean. The lock will take care of that platform-specific CPU ordering, cache flushing, RAM visibility nonsense, with compile-time hints, and runtime instructions, if necessary on your current platform. 

In this particular situation, you could also just use a std::atomic instead of a lock+boolean -- they have functions that let you write a value after also performing a memory-fence operation. 

5 minutes ago, maxest said:

If the above is correct then it doesn't really matter if thread 2 reads memory while thread 1 is halfway writing to it, or does it? Assuming thread 2 is waiting for the variable to be true, then if thread 1 is writing (changing variable from false to true) the thread 2 doesn't really care when it reads true eventually, right?

Due to CPUs reordering things, thread 2 might read the work and then the boolean, or thread 1 might write the boolean and then write the work. Either of those situations would cause thread 2 to process old/uninitialized data instead of thread 1's actual work output. Memory fences (internally handled by locking primitives and std::atomic) make sure that this kind of reordering won't occur (both at compile time and at execution time within the CPU). 

On 10/2/2018 at 4:02 AM, Shaarigan said:

#define SpinLock(__lock) { while (sync_lock_test_and_set(&(__lock), 1)) while (lock) {} } // ERROR: "lock" undefined.

L. Spiro