1 / 8

Readers-Writers Problem

Readers-Writers Problem. Akos Ledeczi EECE 354, Fall 2012 Vanderbilt University. 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:

carter-morse
Télécharger la présentation

Readers-Writers Problem

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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…

More Related