E.g., can the following code ever print "3" for one of the threads?
int foo() { static int a = 1; return ++a; } void thread1() { cout<<foo()<<endl; } void thread2() { cout<<foo()<<endl; } edit: It's C++ 98
2 Answers
Of course it can print 3. It is even the "usual semantics" of this code to do so. Thread 1 initializes it with 1 and increments it, so it is 2. Thread 2 increments it again, so it is 3.
So, yes, scoped static variables are static, i.e., global variables. They are shared by threads.
Of course, the code has a race condition, so the result can possibly be anything, but 3 is a possible result.
3 Comments
Mankarse
The code has undefined behaviour (due to the race condition in
++a), so there are no "usual semantics".
gexicide
still, you will get 3 on most compilers in most situations. But you are right, "usual semantics" is a quite strange word which is not defined anyway, so I placed it in quotes now... Btw: In C++11, the semantics of a program with race conditions is not fully undefined.
Mankarse
Race conditions are definitely fully undefined -- see
[intro.multithread]/21: The execution of a program contains a data race if it contains two conflicting actions in dierent threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.local static variables are shared between threads.
Initialisation of function-local static variables is thread-safe in C++11 (before that, threads did not even exist ;)).
Modification of function-local static variables, on the other hand, is not thread-safe, so your modified code has undefined behaviour (due to the race condition).
9 Comments
TravisG
So they're not shared? If I let one thread wait a second and let the other execute first, the waiting thread will still print 2?
Lightness Races in Orbit
The key here is "C++11". Is the OP using C++11? He didn't mention it. I think we're still at the point where somebody says if they're using C++11, as most people and most production environments are not. And then this initialisation is absolutely not thread-safe.
Christian Rau
@TravisG "So they're not shared?" - No, they are shared. It's only the initialization that is thread-safe (I don't know this, but I believe Mankarse here), so you won't have two threads trying to initialize the variable. The variable itself is shared and even if you synchronize the access, you still have one thread printing 2 and the other 3. And without synchronization it's UB, anyway, as said in the answer.
Jonathan Wakely
@LightnessRacesinOrbit, good compilers have had thread-safe init of statics for years, long before C++11 - you can't say "absolutely" whether the init is safe
Lightness Races in Orbit
@JonathanWakely: In the real world, you can't just "change it" because your code relies on thread-safe function-static initialisation instead of using the appropriate locks suggested by the lack of an implementation guarantee. In the real world, your choice of toolchain comes down to many, many more factors than that and switching toolchains potentially has significant consequences elsewhere. Lots of people have been able to rely on thread-safe init if, like I said, they know for a fact that their version of GCC makes it safe -- I suspect many only think that they can rely on it.
|
2. And there is no race-condition, because the initialization ofais automatically synchronized.