c++ what happens when in one thread write and in second read the same object? (is it safe?)

Question

What happens when in one thread write and in second thread read the same object? It would lead to application crash?

My idea is, on main thread save the data in to object or change the data from object and on second thread only read this data.

If I understand, the problem can be only while writing to object new value and reading in same time from same object, reading value will be old. But this is not problem for me.

I search my question and found this topic What happens if two threads read & write the same piece of memory but I am not sure if it apply for my question.

Answer 1

Unless the object is atomic, the behaviour of one thread writing and another thread reading the same object is undefined .

Your current perception that the only issue is that state data could be read is not correct. You cannot assume that will be only manifestation of the undefined behaviour. In particular, you may well find that the value you read is neither the old nor the new value.

Answer 2

It is not safe. Consider using mutex to avoid memory corruption :

http://en.cppreference.com/w/cpp/thread/mutex

Answer 3

It really depends on the size of the memory block you are trying to read and write from. If you are reading a single atomic data type then you can only read and write to the memory block as a whole (int as an example). You'll either non-deterministic-ally get the new or old value from the data type without any issues.

If you are reading and writing to a block of memory that isn't atomic, then during the reading cycle, some of the blocks can be overwritten and as such, the information can be corrupted. This will lead to some wild behavior and may cause breaks.

https://en.wikipedia.org/wiki/Linearizability

Answer 4

Generally the result is simply undefined. You have to do things to make it defined and you have a lot of docs to read.

1. The compiler has to know that values might be changed from under it. Otherwise the optimizer will do the wrong thing and writes can be completely ignored. The keyword here is volatile . This is required when variables are changed from signal handlers or by the hardware itself. Not sufficient for multithreading.

2. You must ensure that reads and writes are not interrupted. One way to do this is to use atomic types. The other is to protect access to a variable using locks or mutexes. Atomic types are limited in size by what the hardware supports so anything beyond simple integers or single pointers will require locks. The std::atomic type abstracts this away. It knows which types are atomic on your hardware and when it needs to use locking.

3. Even that isn't enough since the timing of reads and writes is still random. If one thread writes and the other reads what will it read? Will the second thread read just before the first writes or just after? Even with all the right use of atomic or locks you don't know weather you will get the old or new value. If that matters you have to synchronize between the threads so the order of reads and writes becomes defined. Look for conditions.