1. Readers-Writers Problem Akos Ledeczi EECE 354, Fall 2012 Vanderbilt University

2. Problem • A number of tasks need to access a shared resource (database, data structure etc.) • Some of them want to modify it (writers), some only need to read it (readers) • Asymmetric problem: 1. Any number of readers can be in the critical section simultaneously. 2. Each writer must have exclusive access to the critical section.

3. First Try • OSMutex access; • int readers = 0; • OSMutexrdCtrl; • void write() • { • … • OSMutexPend(&access,0,OS_OPT_PEND_BLOCKING,&err); • /* critical section for writers */ • OSMutexPost(&access,OS_OPT_POST_1,&ts,&err); • … • } • void read() • { • … • OSMutexPend(&rdCtrl,0,OS_OPT_PEND_BLOCKING,&err); • readers++; • if (readers == 1) • OSMutexPend(&access,0,OS_OPT_PEND_BLOCKING,&err); /* first in locks */ • OSMutexPost(&rdCtrl,OS_OPT_POST_1,&ts,&err); • /* critical section for readers */ • OSMutexPend(&rdCtrl,0,OS_OPT_PEND_BLOCKING,&err); • readers--; • if (readers == 0) • OSMutexPost(&access,OS_OPT_POST_1,&ts,&err); /* last out unlocks */ • OSMutexPost(&rdCtrl,OS_OPT_POST_1,&ts,&err); • … • }

4. Trouble • A high-priority writer will be prevented from accessing the critical section. It will have to wait for the current readers to finish (which is OK), but it will be passed by potentially lower-priority readers arriving later. The writer can even be completely starved by a steady stream of readers. • Priority inheritance does not work here because only the first reader reserves the mutex, so its priority can be elevated by a waiting writer, but all the other readers do not hold the mutex, so they can access the critical section regardless of their and the waiting writer’s priority

5. Second Try • OSMutex access; • OSMutexgateKeeper; • int readers = 0; • OSMutexrdCtrl; • void write() • { • … • OSMutexPend(&gateKeeper,&err); /* to prevent readers from cutting in */ • OSMutexPend(&access,0,OS_OPT_PEND_BLOCKING,&err); • /* critical section for writers */ • OSMutexPost(&gateKeeper,&ts,&err); • OSMutexPost(&access,OS_OPT_POST_1,&ts,&err); • … • } • void read() • { • … • OSMutexPend(&gateKeeper,&err); • OSMutexPost(&gateKeeper,&ts,&err); • /* unchanged from previous version */ • … • }

6. Trouble • A high-priority reader arriving later to the gate will be prevented from entering. It will have to wait for the potentially lower-priority current readers to finish and then for the potentially lower-priority writer to write before it gets a chance to proceed. The first part in “normal” cases would be OK, but here this new reader should be able to access the critical section without waiting, as multiple readers are allowed.

7. The “Ultimate” Solution Event Flag Group (ANY SET trigger) Read Manager inherits priority of highest–priority waiting Reader (our code does this, Flags do not support this unlike Mutex-s) (3) Wr Wr Wr Rd Rd Rd Rd (1) (7) (2) (9) (8) (4) Mutex (5) (12) Data (10) M (12) (11) (6) Message Queue (LIFO, Broadcast)

8. Remarks • Readers can arrive even after the Manager has been triggered: • They still elevate the priority of the Manager while it is still waiting for Writers. • They will still get the result of the actual read operation as long as they get to pending on the message queue before the Manager posts the result. • Potential problem: since the Manager can hold the mutex, µC/OS-III can elevate its priority to that of a waiting Writer. When it resets it, it will set it to the value it was right before it elevated it. If we elevated it further because of a new high-priority Reader, it may get set to a wrong value. In this case, however, I do not think it can actually happen. • Why a message queue, if we flush it and post LIFO anyways? If it was just a shared global variable, it would be the same (at least very similar) readers-writer problem that we began with in the first place…