lethargic.talkative.fish

suppose in one thread I have:

while true {
lock(mutex)
if (shared_var == true) do_thing()
unlock(mutex)
}

and in another thread I have:

shared_var = true
sleep(30)
shared_var = false

(note the lack of a mutex)

what happens and why?

@suricrasia On _which_ CPU and with _which_ compiler specifically? There is an hilarious amount of papers discussing not only the problems of eg. the Java memory model, but first, what _is_ the Java memory model.

@drahflow to be simple (for some definition of simple) let's suppose an x86 cpu with two cores, and the threads are on two different cores

@suricrasia A modern compiler might see that `shared_var` is independent of sleep() and move the first store below it. Then multiscalar CPU will find the second store shadows the first, eliminate the first and voila, nothing happens. (Assuming shared_var is declared volatile, otherwise the compiler might have done this already anyway.) Except when the scheduler interrupts the core in-between the scheduling of the two stores.

@suricrasia IIRC, the one guarantee you get for similar code on x86 (but NOT everywhere) is that stores reach cross-core memory levels in the order the instructions were issued.

@suricrasia Source: AMD x86-64 Programmer's Manual, Vol. 1, Rev. 3.08, page 114 (search for chapter "3.9 Memory Optimization")

@suricrasia The other one being (but irrelevant for this code) that loads from addresses are guaranteed to see data which is not older than it was when the address was loaded. (Even when the address was speculated in reality.) I think this one is more widespread.

@drahflow hmm I thought there was something about functions-with-side-effects that means memory operations don't get re-ordered around function calls. though this might be an annotation you have to add to a function call...

@suricrasia @drahflow function calls are… tricky. There's some *compile-time* re-ordering that can't be done when calling a function that's in an external library (when doing lto, anything goes…), but in this case i think the compiler will know that the sleep() call has no access to shared_var due to aliasing rules, so it could probably combine the stores to it.

@suricrasia @drahflow when running on other cores you might also have memory ordering problems here? I forget about x86 specifically, but you have mutex lock calls (which have "acquire" memory ordering), but you have nothing that does "release" memory ordering after the write, so I'm not sure if or when the core doing the mutex loop will necessarily see the update?

@suricrasia @drahflow FWIW, this would "just work" as expected if instead of a normal bool, you use an atomic type like built into many modern programming languages like e.g. https://doc.rust-lang.org/std/sync/atomic/index.html or https://en.cppreference.com/w/cpp/atomic/atomic where the operations used to store and retrieve the values from the variable do the expected compiler *and* runtime memory ordering.

@suricrasia Rather the other way around: Unknown function (assuming C-like ABI) could do anything (incl. memory fences), therefore no reordering. But sleep(), being presumably a stdlib call, might be annotated not to have that or even inlined by the compiler - think an embedded platform where it's really just a loop.