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

Answer 1

As a rule of thumb, you should lock the read too. Read and write to int is atomic on most architecture (and since int is guaranted to be the machine's word size, you should almost never experience corrupted int)

Yet, the answer from @paxdiablo is correct, and will happen if you have someone doing this:

#pragma pack(push, 1)
  struct MyObj
  {
     char a; 
     MyCounter cnt;
  };
#pragma pack(pop)

In that specific case, cnt will not be aligned to a word boundary, and the int MyCounter::counter will/might be emulated in multiple operations in CPU supporting unaligned access (like x86). Thus, you could get this sequence of operations:

Thread A:   [...] set counter to 255 (counter is 0x000000FF)
            getCount() => CPU reads low byte: lo:255
<interrupted here>
Thread B:   increase() => counter is incremented, leading to counter = 256 = 0x00000100)
<interrupted here>
Thread A:   CPU read high bytes: 0x000001, concatenate: 0x000001FF, returns 511 !

Now, let's say you never use unaligned access. Yet, if you are doing something like this:

   ThreadA.cpp: 
   int g = clientCounter.getCount();
   while (g > 0)
   {
      processFirstClient();
      g = clientCounter.getCount();     
   }

   ThreadB.cpp:
   if (acceptClient()) clientCounter.increase();

The compiler is completely allowed to replace the loop in Thread A by this:

if (clientCounter.getCount()) 
   while(true) processFirstClient();

Why ? That's because for each instruction, the compiler will evaluate side-effects of such expression. The getCount() is so simple that the compiler will deduce: it's a read of a single variable, and it's not modified anywhere in ThreadA.cpp, thus, it's constant. Because it's constant, let's simplify this.

If you add a mutex, the mutex code will insert a memory barrier telling the compiler "hey, don't expect anything after this barrier is crossed". Thus, the "optimization" above can not happen since getCount might have been modified.

Sure, you could have written volatile int counter instead of counter, and the compiler would have avoided this optimization too.

In the end, if you have to write a ton of code just to avoid a mutex, you're doing it wrong (and probably will get wrong results).

Answer 2

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 3

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++)

Answer 4

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 5

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:

(a) add 1 to lower byte
    if lower byte is 0:
(b)     add 1 to upper byte

and the initial value is 255.

If another thread comes in anywhere between the lower byte change a and the upper byte change b, 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.