Looking for critique of my reader/writer implementation [closed] - c++

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
i implemented the readers/writers problem in c++11… I'd like to know what's wrong with it, because these kinds of things are difficult to predict on my own.
Shared database:
Readers can access database when no writers
Writers can access database when no readers or writers
Only one thread manipulates state variables at a time
the example has 3 readers and 1 writer, but also use 2 or more writer....
Code:
class ReadersWriters {
private:
int AR; // number of active readers
int WR; // number of waiting readers
int AW; // number of active writers
int WW; // number of waiting writers
mutex lock;
mutex m;
condition_variable okToRead;
condition_variable okToWrite;
int data_base_variable;
public:
ReadersWriters() : AR(0), WR(0), AW(0), WW(0), data_base_variable(0) {}
void read_lock() {
unique_lock<mutex> l(lock);
WR++; // no writers exist
// is it safe to read?
okToRead.wait(l, [this](){ return WW == 0; });
okToRead.wait(l, [this](){ return AW == 0; });
WR--; // no longer waiting
AR++; // now we are active
}
void read_unlock() {
unique_lock<mutex> l(lock);
AR--; // no longer active
if (AR == 0 && WW > 0) { // no other active readers
okToWrite.notify_one(); // wake up one writer
}
}
void write_lock() {
unique_lock<mutex> l(lock);
WW++; // no active user exist
// is it safe to write?
okToWrite.wait(l, [this](){ return AR == 0; });
okToWrite.wait(l, [this](){ return AW == 0; });
WW--; // no longer waiting
AW++; // no we are active
}
void write_unlock() {
unique_lock<mutex> l(lock);
AW--; // no longer active
if (WW > 0) { // give priority to writers
okToWrite.notify_one(); // wake up one writer
}
else if (WR > 0) { // otherwize, wake reader
okToRead.notify_all(); // wake all readers
}
}
void data_base_thread_write(unsigned int thread_id) {
for (int i = 0; i < 10; i++) {
write_lock();
data_base_variable++;
m.lock();
cout << "data_base_thread: " << thread_id << "...write: " << data_base_variable << endl;
m.unlock();
write_unlock();
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
void data_base_thread_read(unsigned int thread_id) {
for (int i = 0; i < 10; i++) {
read_lock();
m.lock();
cout << "data_base_thread: " << thread_id << "...read: " << data_base_variable << endl;
m.unlock();
read_unlock();
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
};
int main() {
// your code goes here
ReadersWriters rw;
thread w1(&ReadersWriters::data_base_thread_write, &rw, 0);
thread r1(&ReadersWriters::data_base_thread_read, &rw, 1);
thread r2(&ReadersWriters::data_base_thread_read, &rw, 2);
thread r3(&ReadersWriters::data_base_thread_read, &rw, 3);
w1.join();
r1.join();
r2.join();
r3.join();
cout << "\nThreads successfully completed..." << endl;
return 0;
}

Answer 1

Feedback:
1. It is missing all necessary #includes.
2. It presumes a using namespace std, which is bad style in declarations, as that pollutes all of your clients with namespace std.
3. The release of your locks is not exception safe:
write_lock();
data_base_variable++;
m.lock();
cout << "data_base_thread: " << thread_id << "...write: " << data_base_variable << endl;
m.unlock(); // leaked if an exception is thrown after m.lock()
write_unlock(); // leaked if an exception is thrown after write_lock()
4. The m.lock() wrapping of cout in data_base_thread_write is really unnecessary since write_lock() should already be providing exclusive access. However I understand that this is just a demo.
5. I think I see a bug in the read/write logic:
step 1 2 3 4 5 6
WR 0 1 1 1 0 0
AR 0 0 0 0 1 1
WW 0 0 1 1 1 0
AW 1 1 1 0 0 1
In step 1, thread 1 has the write lock.
In step 2, thread 2 attempts to acquire a read lock, increments WR, and blocks on the second okToRead, waiting for AW == 0.
In step 3, thread 3 attempts to acquire a write lock, increments WW, and blocks on the second okToWrite, waiting for AW == 0.
In step 4, thread 1 releases, the write lock by decrementing AW to 0, and signals okToWrite.
In step 5, thread 2, despite not being signaled, is awoken spuriously, notes that AW == 0, and grabs the read lock by setting WR to 0 and AR to 1.
In step 6, thread 3 receives the signal, notes that AW == 0, and grabs the write lock by setting WW to 0 and AW to 1.
In step 6, both thread 2 owns the read lock and thread 3 owns the write lock (simultaneously).
6. The class ReadersWriters has two functions:
It implements a read/write mutex.
It implements tasks for threads to execute.
A better design would take advantage of the mutex/lock framework established in C++11:
Create a ReaderWriter mutex with members:
// unique ownership
void lock(); // write_lock
void unlock(); // write_unlock
// shared ownership
lock_shared(); // read_lock
unlock_shared(); // read_unlock
The first two names, lock and unlock are purposefully the same names as those used by the C++11 mutex types. Just doing this much allows you to do things like:
std::lock_guard<ReaderWriter> lk1(mut);
// ...
std::unique_lock<ReaderWriter> lk2(mut);
// ...
std::condition_variable_any cv;
cv.wait(lk2); // wait using the write lock
And if you add:
void try_lock();
Then you can also:
std::lock(lk2, <any other std or non-std locks>); // lock multiple locks
The lock_shared and unlock_shared names are chosen because of the std::shared_lock<T> type currently in the C++1y (we hope y is 4) working draft. It is documented in N3659.
And then you can say things like:
std::shared_lock<ReaderWriter> lk3(mut); // read_lock
std::condition_variable_any cv;
cv.wait(lk3); // wait using the read lock
I.e. By just creating a stand-alone ReaderWriter mutex type, with very carefully chosen names for the member functions, you get interoperability with the std-defined locks, condition_variable_any, and locking algorithms.
See N2406 for a more in-depth rationale of this framework.