CODEWITHSUNDEEP
multithreadingoperating-systemthread-safety
LumiG
LumiG

Reputation: 462

Is this reader-writer lock implementation correct?

wondering if the following implementation of reader/writer problem correct.

We're using only one mutex and a count variable to indicate the num of readers.

read api:

void read() {
    mutex.lock();
    count ++;
    mutex.unlock();
    // Do read
    mutex.lock();
    count --;
    mutex.unlock();
}

write api:

void write() {
    while(1) {
        mutex.lock();
        if(count == 0) {
            // Do write
            mutex.unlock();
            return;
        }
        mutex.unlock();
    }
}

Looks like in the code:

  1. Only one lock is used so there is no deadlock problem;

  2. Writer can only write when count == 0 so there is no race conditions.

As for a read/write problem prior to reader, is there any problem for the above code? Looks like all the standard implementation uses two locks(eg. https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem#First_readers-writers_problem). If the above implementation seems correct, why are we using two locks in wiki? Thank you!

Upvotes: 2

Views: 82

Answers (1)

David Schwartz
David Schwartz

Reputation: 182819

It's correct, but it will perform atrociously. Imagine if while a reader is trying to do work there are two waiting writers. Those two waiting writers will constantly acquire and release the mutex, saturating the CPU resources while the reader is trying to finish its work so that the system as a whole can make forward progress.

The nightmare scenario would be where the reader shares a physical core with one of the waiting writers. Yikes.

Correct, yes. Useful and sensible, definitely not!

One reason to use two locks is to prevent two writers from competing. A more common solution, at least in my experience, is to use a lock with a condition variable to release waiting writers or alternate phases.

Upvotes: 1

Related Questions