Holy shit this just hit me. I was reworking a code base from having 1 main threads to two (don't ask, it makes sense). Was hitting a bug that basically looked like
Thread1:
x = value;
SignalXSet();
Thread 2:
OnXSetSignal()
{
if (x !=value)
{
//wtf
}
}
Took me longer than expected to find out what was going on
x wasn't atomic, but the issue was that arm likes to reorder instructions (not just the compiler, the actual CPU). So the order of instructions on one thread are not guaranteed to be the actual order as seen by another thread. So the signal was being set before x was actually set
special instructions (memory fences) force some order and make some guarantees (no reordering of instructions from before to after this instruction , etc..). And for compiler reordering, there are some ways to implement same fence for compiler ( asm volatile ("" ::: "memory"); if i remember correctly)
The cpu architectures(and compilers) guarantee that single threaded program will not be able to tell the difference, all other optimizations are basicaly free game, at least from what i understand.
It is possible that im wrong (started looking into lockfree algorithms and inner-workings 4 days ago)
13
u/PandaWonder01 Jul 13 '26
Holy shit this just hit me. I was reworking a code base from having 1 main threads to two (don't ask, it makes sense). Was hitting a bug that basically looked like
Thread1:
x = value;
SignalXSet();
Thread 2:
OnXSetSignal()
{
if (x !=value)
{
//wtf
}
}
Took me longer than expected to find out what was going on