Question

I am new to multithreading world and started getting into it. I found threading requires synchronization. Volatile is no more a reliable thing. I would like to know if synchronization object are cacheable by compiler or at any stage?

Platform/languages used : c++, win32, Windows

In c++, volatile keyword is used for objects which can not be cached by CPUs. But today’s compilers do not strictly follow this. Is there is other way around to make synchronization objects non-cacheable (or other optimizations are not applied on those objects).

tl;dr: Are synchronization objects cacheable? If yes, how can you make it non-cacheable ?

Answer 1

I’m not sure I follow your question: compiler cache has almost nothing to do with multithreading. The only thing that a compiler cache would do is to increase your compilation speed by caching previous compilations.

Synchronization objects can be “cached” since they’re any arbitrary object that you’ve decided to use for synchronization, but that has little effect on concurrency. The only thing that you need to care about when synchronizing is that when you have multiple threads contending for a resource, they must all synchronize on the same object in order to get read/write access to the resource.

I’m going to take a wild guess, based on your mentioning of volatile, and assume that you’re worried a synchronization object may be cached in a thread’s local cache and changes to the synchronization object from one thread may not be visible to another thread. This, however, is a flawed idea:

1. When you call lock() or synchronize() (depending on the language), all you need to care about is that the lock is performed on the same object regardless of the internal state of the object.
2. Once you’ve acquired a lock on an object, any resource that you’re modifying within that lock scope will be modified by only one thread.

3. Generally, you should use a synchronization object that will not change (ideally a readonly, const or final) and we’re only talking about the reference here, not the content of the object itself. Here is an example:

   object sync = new object();
   string something = “hello”:

   void ModifySomething()
   {
   sync = new object();// <– YOU SHOULD NEVER DO THIS!!
   lock(sync)
   {
   something = GenerateRandomString();
   }
   }

Now notice that every time a thread calls ModifySomething, the synchronization object will be replaced by an new object and the threads will never synchronize on the same object, therefore there may be concurrent writes to something.