Could optimization break thread safety?

Question

class Foo{
public:
    void fetch(void)
    {
        int temp=-1;
        someSlowFunction(&temp);
        bar=temp;
    }
    int getBar(void)
    {
        return bar;
    }
    void someSlowFunction(int *ptr)
    {
        usleep(10000);
        *ptr=0;
    }
private:
    int bar;
};

I'm new to atomic operations so I may get some concepts wrong.

Considering above code, assuming loading and storing int type are atomic[Note 1], then getBar() could only get the bar before or after a fetch().

However, if a compiler is smart enough, it could optimize away temp and change it to:

    void Foo::fetch(void)
    {
        bar=-1;
        someSlowFunction(&bar);
    }

Then in this case getBar() could get -1 or other intermediate state inside someSlowFunction() under certain timing conditions.

Is this risk possible? Does the standard prevent such optimizations?

Note 1: http://preshing.com/20130618/atomic-vs-non-atomic-operations/

The language standards have nothing to say about atomicity in this case. Maybe integer assignment is atomic, maybe it isn’t. Since non-atomic operations don’t make any guarantees, plain integer assignment in C is non-atomic by definition.

In practice, we usually know more about our target platforms than that. For example, it’s common knowledge that on all modern x86, x64, Itanium, SPARC, ARM and PowerPC processors, plain 32-bit integer assignment is atomic as long as the target variable is naturally aligned. You can verify it by consulting your processor manual and/or compiler documentation. In the games industry, I can tell you that a lot of 32-bit integer assignments rely on this particular guarantee.

I'm targeting ARM Cortex-A8 here, so I consider this a safe assumption.

If you need sychornization then use a std::mutex or std::atomic — NathanOliver
"assuming loading and storing int type are atomic" When is that true? — Lightness Races in Orbit
"then getBar() could only get the bar before or after a fetch()" Not true. — Lightness Races in Orbit
"if a compiler is smart enough, it could optimize away temp and change it to:" Also not true. — Lightness Races in Orbit
This code is as thread safe as it gets - there are no threads there, no synchronization, no nothing. To get a real answer, I suggest you elaborate on threaded usage here. — SergeyA

anorm anorm · Accepted Answer · 2015-09-30T15:21:11

Compiler optimization can not break thread safety!

You might however experience issues with optimizations in code that appeared to be thread safe but really only worked because of pure luck.

If you access data from multiple threads, you must either

Protect the appropriate sections using std::mutex or the like.
or, use std::atomic.

If not, the compiler might do optimizations that is next to impossible to expect.

I recommend watching CppCon 2014: Herb Sutter "Lock-Free Programming (or, Juggling Razor Blades), Part I" and Part II

Could optimization break thread safety?

4 Answers