9 (6.9) In the readers and writers monitor presented in Fig. 6.3 why does it make sense to cascade in all waiting readers? Could this cause indefinite postponement of waiting writers? Under what circumstances might you choose to limit the number of waiting readers you would initi- ate when reading is allowed? 1 // Fig. 6.3: Readers/writers problem 3 int readers -0: II number of readers 4 boolean writeLockfalse; // true if a writer is writing 5 Condition canWrite; // condition variable 6 Condition canRead; // condition variable 7 8 / monitor entry called before performing read 9 monitorEnt 10 ry void beginRead () /I wait outside monitor if writer is currently writing or if 12 writers are currently waiting to write 13 if writeLock Il queue canWrite) ) 14 15 16 // end if 17 18 +readera; I/ there is another reader 19 20 21 // end beginRead wait( canRead: // wait until reading is allowed eignal canRead// allow waiting readers to proceed 23 // monitor entry called after reading 24 monitorEntry void endReado 25 26 --readers; / there are one fewer readers 27 28 29 30 31 32/1 end if /lif no more readers are reading, allow a writer to write if reader 0) signal (canWriteI/ allow a writer to proceed 34 end endRead 35 36 / monitor entry called before performing write 37 monitorEntry void beginWrite) 39 40 if readers > writeLock) 41 42 43 i end if // wait if readers are reading or if a writer is writing wait canWrite ); I wait unti writing is allowed 45 writeLock true; // "lock out all readers and writers 46 // end beginWrite 47 48 // monitor entry called after performing write 49 monitorEntry void endwrite () 51 writeLockfalse 52 release lock 53I/ if a reader is waiting to enter, signal a reader 54 if ( queue canRead) 56 57 / end if 58 else // signal a writer if no readers are waiting signal( canRead /I cascade in waiting readers 59 60 61// end else signal( canWrite ); // one waiting writer can proceed 62 63 I/ end endwrite Figure 6.3 | Monitor pseudocode for solving the readers and Writers problem 9 (6.9) In the readers and writers monitor presented in Fig. 6.3 why does it make sense to cascade in all waiting readers? Could this cause indefinite postponement of waiting writers? Under what circumstances might you choose to limit the number of waiting readers you would initi- ate when reading is allowed? 1 // Fig. 6.3: Readers/writers problem 3 int readers -0: II number of readers 4 boolean writeLockfalse; // true if a writer is writing 5 Condition canWrite; // condition variable 6 Condition canRead; // condition variable 7 8 / monitor entry called before performing read 9 monitorEnt 10 ry void beginRead () /I wait outside monitor if writer is currently writing or if 12 writers are currently waiting to write 13 if writeLock Il queue canWrite) ) 14 15 16 // end if 17 18 +readera; I/ there is another reader 19 20 21 // end beginRead wait( canRead: // wait until reading is allowed eignal canRead// allow waiting readers to proceed 23 // monitor entry called after reading 24 monitorEntry void endReado 25 26 --readers; / there are one fewer readers 27 28 29 30 31 32/1 end if /lif no more readers are reading, allow a writer to write if reader 0) signal (canWriteI/ allow a writer to proceed 34 end endRead 35 36 / monitor entry called before performing write 37 monitorEntry void beginWrite) 39 40 if readers > writeLock) 41 42 43 i end if // wait if readers are reading or if a writer is writing wait canWrite ); I wait unti writing is allowed 45 writeLock true; // "lock out all readers and writers 46 // end beginWrite 47 48 // monitor entry called after performing write 49 monitorEntry void endwrite () 51 writeLockfalse 52 release lock 53I/ if a reader is waiting to enter, signal a reader 54 if ( queue canRead) 56 57 / end if 58 else // signal a writer if no readers are waiting signal( canRead /I cascade in waiting readers 59 60 61// end else signal( canWrite ); // one waiting writer can proceed 62 63 I/ end endwrite Figure 6.3 | Monitor pseudocode for solving the readers and Writers