Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When you have a situation where Thread A reads some global variable and Thread B writes to the same variable, now unless read/write is not atomic on a single core, you can do it without synchronizing, however what happens when running on a multi-core machine?
Even on a single core, you cannot assume that an operation will be atomic. That may be the case where you’re coding in assembler but, if you are coding in C++ as per your question, you do not know what it will compile down to.
You should rely on the synchronisation primitives at the level of abstraction that you’re coding to. In your case, that’s the threading calls for C++. whether they be pthreads, Windows threads or something else entirely.
It’s the same reasoning that I gave in another answer to do with whether i++ was thread-safe. The bottom line is, you don’t know since you’re not coding to that level (if you’re doing inline assembler and/or you understand and can control what’s going on under the covers, you’re no longer coding at the C++ level and you can ignore my advice).
The operating system and/or OS-type libraries know a great deal about the environment they’re running in, far more so than the C++ compiler would. Use of proper syncronisation primitives will save you a great deal of angst.