1

If one thread in a program attempts to read from a variable while another writes to it, the value read is of course undefined. However, assuming there is only one writer, is the write guaranteed to succeed? For example:

bool myGlobalVariable = false;
void thread1() {
    myGlobalVariable = true;
}
void thread2() {
    bool x = myGlobalVariable; //x is undefined
}

In this case, once both threads are finished, is myGlobalVariable guaranteed to be true?

I'm specifically wondering about gcc on linux, but I'd be interested to know what other operating systems and compilers do, or if ARM behaves differently than x86.

IanPudney
  • 5,941
  • 1
  • 24
  • 39
  • "is the write guaranteed to succeed" What do you think could fail it in case of single writer – ravi Dec 11 '14 at 17:56

2 Answers2

2

In practice nothing probably will fail. However, the C++11/14 standard is pretty clear in this regard. Here is a quote from C++14 draft section [intro.multithread]/23 (emphasis mine):

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior.

Where conflicting actions are defined at [intro.multithread]/6:

Two expression evaluations conflict if one of them modifies a memory location (1.7) and the other one accesses or modifies the same memory location.

Anton Savin
  • 40,838
  • 8
  • 54
  • 90
1

I can't see how this could possibly fail to write the value under any circumstances, if it's just a write and not a read.

The reason that multithreaded access to the same variable is dangerous is precisely that there's no checking being done as to whether the variable is being modified during an operation. It's not that it might check and then complain.

So in the case of a single write, and just a write (so no i++, which is a read as well), it must succeed.

Of course, you could design hardware that would fail if you wanted to, but I don't see how any standard architecture could fail.

As Anton points out in his answer, the spec says it's undefined behaviour, and so it would be possible to write a valid C++ compiler that deliberately watches out for such behaviour and randomises the result. But no compiler is going to do that in practice.

That said, it's never a good idea to rely on behaviour that's officially undefined, so as the comment from jeffamaphone says, the right answer to your question is that the write will succeed, but you still shouldn't do it.

chiastic-security
  • 20,430
  • 4
  • 39
  • 67
  • 1
    Correct answer, but, OP, I still wouldn't do it. :) – i_am_jorf Dec 11 '14 at 18:02
  • Do you mean no read *from that thread*? I'm asking about whether a write could fail if there was a simultaneous read in a different thread. – IanPudney Dec 11 '14 at 18:03
  • A write can be torn and the value read could be incorrect. You should really suggest atomics. I doubt Standard defines concurrency without it. – 2501 Dec 11 '14 at 18:04
  • @2501 the read value might well be incorrect, yes, that's assumed in the question. The question was just whether the write will succeed. – chiastic-security Dec 11 '14 at 18:14
  • @IanPudney I mean no read from the same thread that's writing, yes. – chiastic-security Dec 11 '14 at 18:14
  • The question is: *In this case, once both threads are finished, is myGlobalVariable guaranteed to be true?* and you misunderstood OP as he just clarified. – 2501 Dec 11 '14 at 18:16
  • @2501 yes, myGlobalVariable is the value being written to as it's read from. The value of x is undefined because it's reading concurrently with a write. But the write will succeed, and the value of myGlobalVariable will be true after both threads have finished. – chiastic-security Dec 11 '14 at 18:35
  • Actually the program will display undefined behavior. Take look at the other answer. – 2501 Dec 11 '14 at 18:36
  • @2501 yes, I realise that the spec says it's undefined. The question is whether it can be relied upon in practice. I'll edit my answer to clarify that. – chiastic-security Dec 11 '14 at 19:02