C++ While(1) loop is not calling if statement inside it

Question

I've got an interrupt that sets a flag, a bool called recvd as so:

while (radio.available())
          {
            // Fetch the payload, and see if this was the last one.
            radio.read( &receive_payload, len );
            recvd = 1;
    radio.writeAckPayload(1,&ack,sizeof(ack));
    }

In my main() I've got a while(1) loop and a simple if statement checking if the flag has been set to 1:

// forever loop
while(1){
if (recvd == 1){toFloat(12);recvd = 0;}
}
}

This function is never called, even though I can put a printf inside the interrupt handler giving the value for recvd and it spits out 1. Any Ideas? Interestingly enough, when I put a random character printf just in the root of the while statement the if clause is called.

no - I'm not a C++ programmer so that never occured to me! it works! thank you — foldone, Jun 16 '17 at 16:22
@PeterT: `atomic` would be better than old `volatile` trick. — Jarod42, Jun 16 '17 at 16:32
NEVER use `volatile` for multi-thread access, it's only meant for talking to hardward. Use `std::atomic` instead!!! — JVApen, Jun 16 '17 at 20:20

score 0 · Accepted Answer · answered Jun 16 '17 at 16:38

This is quite a good example of multithreading programming caveats. Actually, there are two of them:

Compiler-level optimization. If your compiler can make a suggestion about values and execution path, it can optimize your code. Sometimes, it does it very significantly (as Shafik Yaghmaour mentioned in comments above).
CPU-level optimization. Modern processors can execute your code very different way compared with what your compiler created. Most famous thing here is "out-of-order execution" which helps CPU to maximize code speed and increase memory/conveyor/etc throughputs. So, if your CPU decides there is no correlation between that two statements, it is no difference if they're executed in original order or in inversed order. Thus, one thread can run very ahead of another (and destroy your code logic). To avoid that, you have to learn about memory fences and other synchronization primitives, how they can affect your code.

#2 mixes two very distinct concepts. OOOE is a thing, but only internally at a CPU microarchitectural level. At least on x86, it is required that all instructions be *retired* in the order they were originally issued in, so from the programmer's perspective, everything looks just as if it were executed in order. The mixup, though, is that OOOE has nothing to do with *different threads* running ahead of each other. That's just a regular old race condition, solved, as you accurately prescribe, with properly written synchronization code. — Cody Gray - on strike, Jun 16 '17 at 16:41
@CodyGray, that's totally right, I just mean that without OoOE you may be lucky enough to never meet that strange behavior (as threads execution speed could be regular enough to make that poor code working). But OoOE is totally to ruin that luck. — Yury Schkatula, Jun 17 '17 at 12:01

C++ While(1) loop is not calling if statement inside it

1 Answers1