Why do we need read locks in read-write locks?

Question

in read-write locks, why do we need read locks since processes can read a file at the same time? Would only a write lock suffice? Thanks.

Answer 1

A read lock allows multiple concurrent readers of some data, but it prevents readers from accessing the data while a writer is in the middle of changing it. That ensures that a reader will never see a partial update (a state where the writer has updated some parts of the data but not all of them. This state is usually inconsistent).

A writers lock alone is not sufficient, because reading and writing typically happen in different sections of code (different functions). A typical arrangement would be

class Resource
{
public:
  read()
  {
    acquire read lock;
    create a local copy of the resource's data;
    release read lock;
    return local copy;
  }
  write(new data)
  {
    acquire write lock;
    modify resource's data
    release write lock;
  }
}

Thew read and write locks coordinate to allow either multiple readers or a single writer access to the resource, but never multiple writers or both a writer and a reader at the same time.

If you only use write locks, then the effect is the same as using simple exclusive-access locks and only a single thread can either read or write the resource.

Answer 2

An update lock is an exclusive lock, that is, only one lock can be held at a time. It is used to prevent concurrent updates.

A read lock is a shared lock, multiple readers can held a read lock simultaneously. A read lock conflicts when some other threads takes an update lock. The purpose of read lock is to block updates while the read lock is being held and to block reading data that is in the middle of an update, in other words, while a read lock is held the data cannot be modified.

If your system doesn't have shared/read lock mechanism, it's possible to prevent updates while reading the data using by taking update lock instead. However, an exclusive lock is too broad, it comes at the cost of significantly reduced read concurrency, as it means only one reader can read simultaneously.

Answer 3

Presuming a write cannot be done atomically:

Only one thread at a time can safely write data without corruption.

No reads can happen during a write without getting corrupt data.

Multiple reads can safely run concurrently as long as the data does not change.

Thus:

Only one thread at a time can hold the write lock.

When a thread is holding the write lock, no read locks can be obtained.

When one or more threads are holding read locks, the write lock cannot be obtained.

Multiple reads can run concurrently without blocking, increasing throughput if your use case is read-heavy.

Answer 4

A read-lock is "a lock you set when you read", instead of "a lock to prevent others from reading". The confusion here is mostly triggered by your understanding of the terminology. Mostly your understanding is correct: All the troubles in multi-process/multi-thread are caused by writing.

If no writing occurs in the whole procedure, no matter how many people are reading the file at the same time, as long as they keep a separate read pointer, we'll be fine.

But when you are trying to write, how do you know if there's anyone reading the content? You have no way of knowing it! That's why we have a read-lock, a lock that is set when someone is reading the content, so that when someone is trying to write, they'll know that it's not an appropriate timing to write.

Answer 5

If I modify a file right now, and you could read it while I modify it, you’d get an unpredictable mix of old and new data, and things would go wrong. Same if you were reading data and I started modifying it.

A write lock means: I cannot get the write lock as long as someone else holds a write or read lock (because me starting to write would interfere both with a read or writer). And it prevents others from getting a read or write lock.

A read lock means: I cannot get the read lock as long as someone else holds a write lock (because I shouldn’t read while someone else is writing). And it prevents others from getting a write lock while I’m reading. But any number of people can get read locks and read simultaneously without problems.

Note that this doesn’t solve all problems. If I read a file into memory, and one microsecond later you modify the file, then what I have in memory doesn’t reflect the contents of the file anymore. This could cause all kinds of problems on a higher level (but not on the lower level where we prevent reading an inconsistent file).