What does a read lock do in C++?

Question

When using a shared_mutex, there is exclusive access and shared access. Exclusive access only allows one thread to access the resource while others are blocked until the thread holding the lock releases the lock. A shared access is when multiple threads are allowed to access the resource but under a "read lock". What is a "read lock"? I don't understand the meaning of a read lock. Can someone give code examples of a "read lock".

My guess of a read lock: I thought that a read lock only allows threads to run the code and not modify anything. Apparently I was wrong when I tried some code and it didn't work as I thought.

Again, can someone help me understand what a read lock is.

Thanks.

Answer 1

Your guess is very close to being right but there's a slight subtlety.

The read/write distinction shows intent of the locker, it does not limit what the locker actually does. If a read-locker decides to modify the protected resource, it can, and hilarity will ensue. However, that's no different to a thread modifying the protected resource with no lock at all. The programmer must follow the rules, or pay the price.

---

As to the distinction, a read lock is for when you only want to read the shared resource. A billion different threads can do this safely because the resource is not changing while they do it.

A write lock, on the other hand, means you want to change the shared resource, so there should be no readers (or other writers) with an active lock.

It's a way of optimising locks based on usage. For example, consider the following lock queue, with the earliest entries on the right, and no queue jumping (readers jumping in front of writers if the writer is currently blocked) allowed:

(queue here) -> RR W RRRR -> (action here)

• The "resource controller" can allow all four R lockers at the queue head access at the same time.
• The W locker will then have to wait until all of those locks are released before gaining access.
• The final two R lockers must wait until the W locker releases but can then both get access concurrently.

In other words, the possible lock holders at any given time are (mutually exclusive):

• any number of readers.
• one writer.

---

As an aside, there are other possible optimisation strategies you can use as well.

For example (as alluded to earlier), you may want a reader to be able to jump the queue if it looks like the writer would have to wait a while anyway (such as there being a large number of current readers).

That's fraught with danger since you could starve a write locker, but it can be done provided there are limits on the number of queue jumpers.

I have done it in the past. From memory (a long ago memory of an embedded OS built in BCPL for the 6809 CPU, which shows more of my age than I probably want to), the writer included with its lock request the maximum number of queue jumpers it was happy with (defaulting to zero), and the queueing of future readers took that into account.

Answer 2

A write-lock only allows one lock to be acquired at a time.

A read-lock only allows other read-locks to be acquired at the same time, but prevents write-locks.

If you try to acquire a write-lock, you will be forced to wait until every other lock (read or write) has been released. Once you have the write-lock, no one else can get a lock of either kind.

If you try to acquire a read-lock, you will have to wait for any write-lock to be released. If there is no write-lock, you will obtain the read-lock, regardless how many other threads have a read-lock.

Whether or not you modify data is entirely up to you to police. If you have a read-lock, you should not be modifying shared data.