CODEWITHSUNDEEP
c++
Ashley Duncan
Ashley Duncan

Reputation: 1019

C++ Are copies of variables optimised out?

Given a single core CPU embedded environment where reading and writing of variables is guaranteed to be atomic, and the following example:

struct Example
{
    bool TheFlag;

    void SetTheFlag(bool f) {
        Theflag = f;
    }

    void UseTheFlag() {
        if (TheFlag) {
            // Do some stuff that has no effect on TheFlag
        }
        // Do some more stuff that has no effect on TheFlag
        if (TheFlag) {
            ...
        }
    }
};

It is clear that if SetTheFlag was called by chance on another thread (or interrupt) between the two uses of TheFlag in UseTheFlag, there could be unexpected behavior (or some could argue it is expected behavior in this case!).

Can the following workaround be used to guarantee behavior?

void UseTheFlag() {
    auto f = TheFlag;
    if (f) {
        // Do some stuff that has no effect on TheFlag
    }
    // Do some more stuff that has no effect on TheFlag
    if (f) {
        ...
    }
}

My practical testing showed the variable f is never optimised out and copied once from TheFlag (GCC 10, ARM Cortex M4). But, I would like to know for sure is it guaranteed by the compiler that f will not be optimised out?

I know there are better design practices, critical sections, disabling interrupts etc, but this question is about the behavior of compiler optimisation in this use case.

Upvotes: 0

Views: 69

Answers (2)

David Schwartz
David Schwartz

Reputation: 182769

The C++ standard does not say anything about what will happen in this case. It's just UB, since an object can be modified in one thread while another thread is accessing it.

You only say the platform specifies that these operations are atomic. Obviously, that isn't enough to ensure this code operates correctly. Atomicity only guarantees that two concurrent writes will leave the value as one of the two written values and that a read during one or more writes will never see a value not written. It says nothing about what happens in cases like this.

There is nothing wrong with any optimization that breaks this code. In particularly, atomicity does not prevent a read operation in another thread from seeing a value written before that read operation unless something known to synchronize was used.

If the compiler sees register pressure, nothing prevents it from simply reading TheFlag twice rather than creating a local copy. If the compile can deduce that the intervening code in this thread cannot modify TheFlag, the optimization is legal. Optimizers don't have to take into account what other threads might do unless you follow the rules and use things defined to synchronize or only require the explicit guarantees atomicity replies.

You go beyond that, so all bets are off. You need more than atomicity for TheFlag, so don't use a type that is merely atomic -- it isn't enough.

Upvotes: 1

catnip
catnip

Reputation: 25388

You might consider this from the point of view of the "as-if" rule, which, loosely stated, states that any optimisations applied by the compiler must not change the original meaning of the code.

So, unless the compiler can prove that TheFlag doesn't change during the lifetime of f, it is obliged to make a local copy.

That said, I'm not sure if 'proof' extends to modifications made to TheFlag in another thread or ISR. Marking TheFlag as atomic (or volatile, for an ISR) might help there.

Upvotes: 1

Related Questions