Thread synchronization needed for read only data?

JohnSantaFe used Ask the Experts™
I have an application with two threads in addition to the main thread.  There is a shared data resource which consists of a bunch of configuration parameters.  The main application determines all the parameters and then creates the other two threads.  Once established the parameters never change, however they are used by all three threads.

Do I still need to implement synchronization e.g. a mutex to protect the data, or since it never chages, locking is not necessary?  Or another way to put it, is it ok to have multiple threads read data at the same time without locking it?

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
>>Or another way to put it, is it ok to have multiple threads read data at the same time without locking it?

If the data is not changed by the multiple threads, then it's OK to access the data without locking access to it.

You should make the data constant, or access the data from the multiple threads using a constant type, so as to make sure the object is not calling a member that might be modifying the object.
Top Expert 2012
>>or since it never chages, locking is not necessary?

I am known as a synchronization freak, but if that data is never accessed for writing and that is guaranteed, you can safely skip that locking.
To add to above information:

Data shared among threads can be sorted into 4 categories:

A: data dynamically growing or shrinking
samples are message queues, caches, error logs, current filename, ...
B: fixed sized data with varying contents where it was necessary that any thread
    has the most recent value.
samples are boolean flags or counters, e. g. the next unique id number to use or a stop flag or lock flag.

C: fixed sized data with varying contents where it doesn't matter
     whether a thread reads the old or the new contents.  
e. g. a progress indicator which periodically was updated or information about the current status.

D: data with fixed (constant) data.

The most dangerous category is A cause the data contains pointers which might get invalid - at least for a short period. Think of a string which was changed and where the internal buffer was replaced. If one thread has access to the old buffer or old address while the other currently deletes (frees) that allocation it might crash even when there is a read access only.

The B category isn't as dangerous cause the allocation keeps valid. However, if one thread reads the (old) data while it is changed nearly same time by the second thread, it can cause severe logical errors. e. g. a unique id number isn't unique cause two threads read the same number before update. Or a lock flag was not recognized, hence the following operation was not exclusively as it should be. You can solve these issues by using a technique like traffic lights, where both have to stop before exactly one may proceed (green lights) in a predefined order. The recommended way to solve cases A and B is to use a mutex or any other synchronisation object the compiler or the operation system provides. These objects guarantee that only a predefined number of threads (mostly exact one) have access while the others a re blocked means they have to wait until the lock was released.

For C and D cases you don't need synchronisation cause there is no issue if two or more threads read/write to the same address as long as it doesn't matter whether they read the old or the new value. Be aware that dynamically sized strings - or strings at all - are in category A cause they are char arrays which need synchronization while the array was updated.

Regards, Alex



Thanks for the info and validation.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial