Do I need Read-Write lock here

Question

I have writing a multi threaded code. I am not sure, whether I would need a read and write lock mechanism. Could you please go through the usecase and tell me do I have to use read-write lock or just normal mutex will do.

Use case: 1) Class having two variables. These are accessed by every thread before doing operation. 2) When something goes wrong, these variables are updated to reflect the error scenarios. Thus threads reading these variables can take different decisions (including abort)

Here, in second point, I need to update the data. And in first point, every thread will use the data. So, my question is do I have to use write lock while updating data and read lock while reading the data. (Note: Both variables are in memory. Just a boolean flag & string)

I am confused because as my both vars are in memory. So does OS take care when integrity. I mean I can live with 1 or 2 threads missing the updated value when some thread is writing the data in mutex.

Please tell if I am right or wrong? Also please tell If I have to use read-write lock or just normal mutex would do.

Update: I am sorry that I did not give platform and compiler name. I am on RHEL 5.0 and using gcc 4.6. My platform is x86_64. But I don not want my code to be OS specific because we are going to port the code shortly to Solaris 10.

Answer 1

First off, ignore those other answerers talking about volatile. Volatile is almost useless for multithreaded programming, and any false sense of safety given by it is just that - false.

Now, whether you need a lock depends on what you're doing with these variables. You will need a memory barrier at least (locks imply one).

So let's give an example:

• One flag is an error flag. If zero, you continue, otherwise, you abort.
• Another flag is a diagnostic code flag. It gives the precise reason for the error.

In this case, one option would be to do the following:

• Read the error flag without a lock, but with read memory barriers after the read.
• When an error occurs, take a lock, set the diagnostic code and error flags, then release the lock. If the diagnostic code is already set, release the lock immediately.

The memory barriers are needed, as otherwise the compiler (or CPU!) may choose to cache the same result for every read.

Of course, if the semantics of your two variables are different, the answer may vary. You'll need to be more specific.

Note that the exact mechanism for specifying locks and memory barriers depends on the compiler. C++0x provides a portable mechanism, but few compilers fully implement the C++0x standard yet. Please specify your compiler and OS for a more detailed answer.

As for your output data, you will almost certainly need a lock there. Try to avoid taking these locks too often though, as too much lock contention will kill your performance.

Answer 2

If they are atomic variables (C1x stdatomic.h or C++0x atomic), then you don't need read/write locks. With earlier C/C++ standards, there's no portable way of using multiple threads at all, so you need to look into how the implementation you are using does things. In most implementations, data types that can be accessed with a single machine instruction are atomic.

Note that just having an atomic variable is not enough -- you probably also need to declare it as volatile to guarantee that the compiler does not do things that will cause you to miss updates from other threads.

Answer 3

Thus threads reading these variables can take different decisions (including abort)

So each thread need to ensure that it reads the updated data. Also since the variables are shared, you need to take care about the race condition as well.

So in short - you need to use read/write locks when reading and writing to these shared variables.

See if you can use volatile variables - that should save you from using locks when you read the values (however write should still be with locks). This is applicable only because you said that -

I mean I can live with 1 or 2 threads missing the updated value when some thread is writing the data in mutex