Additional Hints for Project #2
(10/13/2005)

Suppose the below scenario (just "manually" designed for illustration): 

READER ENTER 1
WRITER BLOCKED 1
READER BLOCKED 2
READER BLOCKED 3
READER LEAVE 1
WRITER ENTER 1
WRITER BLOCKED 2
READER BLOCKED 4
WRITER LEAVE 1
READER ENTER 2
READER ENTER 3
READER LEAVE 2
READER LEAVE 3
WRITER ENTER 2
WRITER LEAVE 2
READER ENTER 4
READER LEAVE 4
....

Note, reader 4 requests after writer 2 requests. Therefore, reader 4 can
get served only after writer 2 finishes. 
It is wrong to wake up reader 4 when you wake up reader 2 and reader 3.
Reader 4 can not bypass the write 2 to get execution. 
(If you implement in the way that reader 4 is woke up with reader 2 and 3,
this solution is acceptable with minor penalties).


Below is just my suggestion (again, you can choose your own way for implementation):

You can maintain a queue. Every queue entry can be R/W. When a Reader/Write
get blocked, you append a R/W to the queue. So when it is time to wake up
reader/write, you can check that queue, to know how many reader you need to
wake up (for writer, you can only wake up 1 write).

Again consider the above example:
/*----------------------------------------------------------*/
Reader/Writer Sequence       |      Queue Staus
/*----------------------------------------------------------*/
READER ENTER 1               |      Empty
WRITER BLOCKED 1             |      W
READER BLOCKED 2             |      WR
READER BLOCKED 3             |      WRR
READER LEAVE 1               |
WRITER ENTER 1               |      RR
WRITER BLOCKED 2             |      RRW
READER BLOCKED 4             |      RRWR
WRITER LEAVE 1               |      
READER ENTER 2               |      RWR
READER ENTER 3               |      WR
READER LEAVE 2               |      
READER LEAVE 3               |
WRITER ENTER 2               |      R
WRITER LEAVE 2               |      
READER ENTER 4               |      Empty
READER LEAVE 4               |
/*----------------------------------------------------------*/


Some students have the problem with the monitor implementation. As the manual of BACI said, 
"The Immediate Resumption Requirement is implemented in BACI by suspending the 
signaller of a condition and picking (at random) one of the waiters on the condition
with the appropriate priority to run".

If we don't control the priority, which waiter to be woke up is randomly picked. The 
output is likely differnt from the above requirement, but is still acceptable with 
some minor penalties, according to Dr Montagne. 
As you need to implement both semaphore and monitor, every implemntation will 
take up 50%. If your monitor program is not consistent with the above requirment due
to the priority control, 15 points will be off your grade (5 points in result, and 10
points in application logic). So actually you will lose 15 * 0.5 = 7.5 points.

Regarding to monitor implementation, I recommend you to control the priority using:

void waitc( condition cond, int prio );
The monitor process (and hence, also the outside process calling the monitor process) is 
blocked and assigned the priority prio for being re-awakened

You maintain an additional priority variable PA. When a reader/write call waitc, you 
increase PA by one and set the priority of reader/write as PA. So now we wake up waiting
process in FIFO order. 

If you find anything wrong, please eamil me haocheng @ cs.ucf.edu.