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.

  • 1
    If a resource can be read and written atomically, then no locks are needed. But most resources do not offer atomic access, neither reading nor writing. A single logical update may require multiple physical writes, and it is this disparity that creates the need for coordination between readers & writers. See also en.wikipedia.org/wiki/Linearizability.
    – Erik Eidt
    Commented Nov 29, 2020 at 17:30
  • What do you understand about the semantics of read-write locks? Can you think of anything they prevent that your scheme wouldn't?
    – Useless
    Commented Nov 30, 2020 at 10:27
  • Some of the answers here may also be helpful.
    – Leponzo
    Commented May 19, 2021 at 2:27

5 Answers 5


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
    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.

  • 1
    Thanks. Then doesn't a writer lock alone achieve that?
    – Tim
    Commented Nov 29, 2020 at 11:43
  • @Tim, see my update Commented Nov 29, 2020 at 11:57
  • @Tim In the phrase "FOO lock", FOO refers to the one who listens to a lock. In other words, only writers would listen to (and halt because of) a writer lock. That doesn't solve the issue of making readers hald when a write is in progress. I concede that it is confusing since the listeners are often also the ones who close/open the lock themselves; but the above referenced issue has a different listener (reader) and closer/opener (writer), so the distinction becomes importent.
    – Flater
    Commented Aug 1, 2022 at 14:36

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.

  • 1
    TL;DR: fast reads
    – Basilevs
    Commented Nov 30, 2020 at 9:39

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.


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.


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.


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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.