Readers Writers locks in C++ - c++

Question

I have been looking to implement a solution for readers-writers problem using threading/synchronization constructs introduced since c++11.
I ran into this question, the most voted answer has this code -
Reader Thread
// --- read code
rw_mtx.lock(); // will block if there is a write in progress
read_count += 1; // announce intention to read
rw_mtx.unlock();
cell_value = data_base[cell_number];
rw_mtx.lock();
read_count -= 1; // announce intention to read
if (read_count == 0) rw_write_q.notify_one();
rw_mtx.unlock();
Writer Thread
// --- write code
std::unique_lock<std::mutex> rw_lock(rw_mtx);
write_count += 1;
rw_write_q.wait(rw_lock, []{return read_count == 0;});
data_base[cell_number] = cell_value;
write_count -= 1;
if (write_count > 0) rw_write_q.notify_one();
In the writer thread, before writing to data_base[cell_number], shouldn't there be a memory-barrier/fence, to synchronize access to that shared memory?(Same for reader thread)
If you agree withe the above(yay!), how can this be acheived? Looking to improve my understanding here.
Thanks for your help!

Answer 1

Memory barriers in high level programming languages are considered intrinsic to the behavior of the locks provided by the language. From Wikipedia's Memory Barrier page:
Multithreaded programs usually use synchronization primitives provided by a high-level programming environment, such as Java and .NET Framework, or an application programming interface (API) such as POSIX Threads or Windows API. ... In such environments explicit use of memory barriers is not generally necessary.
Wikipedia
If you dig into the source code of pthread_mutex_lock, for example, you will see reliance on futex and atomic exchange functions, which would use a memory barrier.
Your comments seem to indicate that you do not understand why the code sample you pulled from the answer implements a readers-writer lock.
As mentioned in the answer you cited, the code you show has a fairness issue, in that a waiting writer may get starved out by a constant stream of readers. However, if we ignore that issue for now, let us first agree that:
1. No writer will enter the critical section if there is already at least one reader in the critical section.
This is because the condition variable waits for the reader count to reach zero. The way a condition variable works is that it releases the mutex if the condition is false, and acquires the lock when it is signaled. Upon acquiring the mutex, it re-tests the condition, and continues its hold on the mutex if the condition is true.
2. When there are no readers, only one writer will enter the critical section.
The critical section for the writer is both the reader count state of the readers writer lock and section of code that requires write lock protection.
Since the mutex is held when the condition is true, and the lock provides exclusive access, there is only one writer in the critical section which will be writing a new value into the array.
Upon completing the critical section, a new signal is raised on the condition variable to wake up any other waiters and the governing mutex is then released. Since the mutex provides exclusive access, upon release, only one thread will be allowed to acquire the mutex, whether it is a pending writer or reader.
3. Multiple readers may enter the read critical section.
The critical section for a reader is treated differently than the writer. For the reader, we assume the state of the array is synchronized with the most recent write when the lock is acquired. But, reads will not alter the state of the array. So, the acquired mutex critical section is the reader count. Meanwhile, the readers-writer lock (implemented using the mutex and condition variable) critical section includes the part of the code that requires read access to the array.
So, on entering a critical section, the acquired mutex is used to increment the reader count. Once the reader count is non-zero, the readers-writer lock is now being held by a reader and will cause writers to wait on the condition variable. Once the reader count is incremented, the acquired mutex can be released.
Since the mutex was released, a different reader thread can now acquire the mutex and also increment the reader count, and then release the mutex. This allows multiple readers to enter the read critical section. The readers-writer lock remains held for reading since the reader count is positive. The mutex is released to allow other readers to enter.
Upon completing the read critical section, the mutex is acquired to decrement the reader count. If the count is zero, a signal on the condition variable is raised to wake up any pending writers. Then, the mutex is release.
If you looked towards the end of the answer you cited, you would have noticed a mention that C++17 has introduced a much nicer way to implement readers-writer locks. That would be with a shared_mutex.
class DataBase {
// ...
mutable std::shared_mutex rwlock_;
std::vector<ElementType> data_base_;
// ...
ElementType reader (int n) const {
std::shared_lock lock(rwlock_);
return data_base_[n];
}
// ...
void writer (int n, ElementType v) {
std::unique_lock lock(rwlock_);
data_base_[n] = v;
}
// ...
};