memory-model

Here is the originan question, but mine have some differences with it. C++ memory model - does this example contain a data race? My question: //CODE-1: initially, x == 0 and y == 0 if (x) y++; // pthread 1 if (y) x++; // pthread 2 Note: the code above is written in C, not C++ (without a memory model). So does it contain a data race? From my point of view: if we view the code in Sequential Consistency memory model, there is no data race because x and y will never be both non-zero at the same time. However, we can never assume a Sequential Consistency memory model, so the compilier reordering

My question involves std::atomic and the data that this pointer points to. If in thread 1 I have Object A; std:atomic<Object*> ptr; int bar = 2; A.foo = 4; //foo is an int; ptr.store(*A); and if in thread 2 I observe that ptr points to A, can I be guaranteed that ptr->foo is 4 and bar is 2? Does the default memory model for the atomic pointer (Sequentially consistent) guarantee that assignments on non atomic (in this case A.foo) that happen before an atomic store will be seen by other threads before it sees the assignment of the same atomic.store for both cases? If it helps or matters, I am

Does volatile sig_atomic_t give any memory order guarantees? E.g. if I need to just load/store an integer is it ok to use? E.g. here: volatile sig_atomic_t x = 0; ... void f() { std::thread t([&] {x = 1;}); while(x != 1) {/*waiting...*/} //done! } is it correct code? Are there conditions it may not work? Note: This is a over-simplifed example, i.e. I am not looking for a better solution for the given piece of code. I just want to understand what kind of behaviour I could expect from volatile sig_atomic_t in a multithreaded program according to the C++ standard. Or, if it is a case, understand

I'm aware that a synchronizes-with relationship will occur between a release store operation in thread 2 and a acquire load operation in thread 1 even if that load operation isn't directly reading the value stored by thread 2, provided that there is a "release sequence" between the release store operation and the store that is actually being read as long as: The store that is actually being read is in the same thread as the release store operation. In modification-order there is no store in other threads between the release store operation and the store that is actually being read (read-modify

I was reading Bjarne Stroustrup's C++11 FAQ and I'm having trouble understanding an example in the memory model section. He gives the following code snippet: // start with x==0 and y==0 if (x) y = 1; // thread 1 if (y) x = 1; // thread 2 The FAQ says there is not a data race here. I don't understand. The memory location x is read by thread 1 and written to by thread 2 without any synchronization (and the same goes for y ). That's two accesses, one of which is a write. Isn't that the definition of a data race? Further, it says that "every current C++ compiler (that I know of) gives the one

In his great book 'C++ Concurrency in Action' Anthony Williams writes the following (page 309): For example, on x86 and x86-64 architectures, atomic load operations are always the same, whether tagged memory_order_relaxed or memory_order_seq_cst (see section 5.3.3). This means that code written using relaxed memory ordering may work on systems with an x86 architecture, where it would fail on a system with a finer- grained set of memory-ordering instructions such as SPARC. Do I get this right that on x86 architecture all atomic load operations are memory_order_seq_cst ? In addition, on the

This question already has answers here : Closed 8 years ago . Possible Duplicate: What is the difference between char s[] and char *s in C? More of a general question rather than trying to fix something, I've been reading the C programming language book and they take care to make the distinction between char amessage[] = "blah"; char *pmessage = "blah"; The difference being one is a char array and the other a pointer to a string constant. They say modifying the char array is acceptable but you shouldn't modify string constants as it triggers undefined behavior. My question is: isn't the string