Multithreading: do I need protect my variable in read-only method?

Question

I have few questions about using lock to protect my shared data structure. I am using C/C++/ObjC/Objc++

For example I have a counter class that used in multi-thread environment

class MyCounter {
private:
    int counter;
    std::mutex m;

public:
    int getCount() const {
        return counter;
    }
    void increase() {
        std::lock_guard<std::mutex> lk(m);
        counter++;
    }
};

1. Do I need to use std::lock_guard<std::mutex> lk(m); in getCount() method to make it thread-safe?

2. What happen if there is only two threads: a reader thread and a writer thread then do I have to protect it at all? Because there is only one thread is modifying the variable so I think no lost update will happen.

3. If there are multiple writer/reader for a shared primitive type variable (e.g. int) what disaster may happen if I only lock in write method but not read method? Will 8bits type make any difference compare to 64bits type?

4. Is any primitive type are atomic by default? For example write to a char is always atomic? (I know this is true in Java but don't know about c++ and I am using llvm compiler on Mac if platform matters)

Answer 1

Yes, unless you can guarantee that changes to the underlying variable counter are atomic, you need the mutex.

Classic example, say counter is a two-byte value that's incremented in (non-atomic) stages:

add 1 to lower byte
if lower byte is 0:
    add 1 to upper byte

and the initial value is 255.

If another thread comes in anywhere between the lower byte change and the upper byte change, it will read 0 rather than the correct 255 (pre-increment) or 256 (post-increment).

In terms of what data types are atomic, the latest C++ standard defines them in the <atomic> header.

If you don't have C++11 capabilities, then it's down to the implementation what types are atomic.

Answer 2

Yes, you would need to lock the read as well in this case.

There are several alternatives -- a lock is quite heavy here. Atomic operations are the most obvious (lock-free). There are also other approaches to locking in this design -- the read write lock is one example.

Answer 3

Yes, I believe that you do need to lock the read as well. But since you are using C++11 features, why don't you use std::atomic<int> counter; instead?

Answer 4

You cant gaurantee that multiple threads wont modify your variable at the same time. and if such a situation occurs your variable will be garbled or program might crash. In order to avoid such cases its always better and safer to make the program thread safe.

You can use the synchronization techinques available like: Mutex, Lock, Synchronization attribute(available for MS c++)