Do I need a mutex for reading?

Question

I have a class that has a state (a simple enum) and that is accessed from two threads. For changing state I use a mutex (boost::mutex). Is it safe to check the state (e.g. compare state_ == ESTABLISHED) or do I have to use the mutex in this case too? In other words do I need the mutex when I just want to read a variable which could be concurrently written by another thread?

Answer 1

Yes. If thread a reads a variable while thread b is writing to it, you can read an undefined value. The read and write operation are not atomic, especially on a multi-processor system.

Answer 2

Generally speaking you don't, if your variable is declared with "volatile". And ONLY if it is a single variable - otherwise you should be really careful about possible races.

Answer 3

This question has a good discussion on this very topic:

Is it safe to read an integer variable thats being concurrently modified?

Answer 4

The access to the enum ( read or write) should be guarded.

Another thing: If the thread contention is less and the threads belong to same process then Critical section would be better than mutex.

Answer 5

Yes, but the interlocked class will be easier to work with

Answer 6

You have two threads, they exchange information, yes you need a mutex and you probably also need a conditional wait.

In your example (compare state_ == ESTABLISHED) indicates that thread #2 is waiting for thread #1 to initiate a connection/state. Without a mutex or conditionals/events, thread #2 has to poll the status continously.

Threads is used to increase performance (or improve responsiveness), polling usually results in decreased performance, either by consuming a lot of CPU or by introducing latencey due to the poll interval.

Answer 7

You know Lightweight Lock, easy to use and very fast. For Windows environment.

Good article about Understand the Impact of Low-Lock Techniques in Multithreaded Apps

Answer 8

actually, there is no reason to lock access to the object for reading. you only want to lock it while writing to it. this is exactly what a reader-writer lock is. it doesn't lock the object as long as there are no write operations. it improves performance and prevents deadlocks. see the following links for more elaborate explanations :

wikipedia codeproject

Answer 9

It depends.

The C++ language says nothing about threads or atomicity.

But on most modern CPU's, reading an integer is an atomic operation, which means that you will always read a consistent value, even without a mutex.

However, without a mutex, or some other form of synchronization, the compiler and CPU are free to reorder reads and writes, so anything more complex, anything involving accessing multiple variables, is still unsafe in the general case.

Assuming the writer thread updates some data, and then sets an integer flag to inform other threads that data is available, this could be reordered so the flag is set before updating the data. Unless you use a mutex or another form of memory barrier.

So if you want correct behavior, you don't need a mutex as such, and it's no problem if another thread writes to the variable while you're reading it. It'll be atomic unless you're working on a very unusual CPU. But you do need a memory barrier of some kind to prevent reordering in the compiler or CPU.