Straight out of the notes, this one:counterValue = i + s - numberOfWAITsbut...counterValue >= 0therefore...i + s - numberOfWAITs >= 0or
i + s >= numberOfWAITsnumberOfWAITs <= i + s
Some other process doing a WRITE into the pipe would unblock it (the READer, that is, not the pipe :-).
This will only happen if the pipe's internal buffer is full. The WRITEr will become unblocked once some other process has READ some bytes.
With a rendezvous, messages are not queued.The SENDer must wait for some other task to RECEIVE; a RECEIVEr must wait for another task to SEND. (SEND and RECEIVE are synchronous with a rendezvous; asynchronous in a message-passing system which queues messages.)
This is the producer-consumer problem. Use 3 semaphores:const int BUFFER_CAPACITY = 100; // Say, for example.The code for the producer is:
Semaphore emptySlots = new Semaphore(BUFFER_CAPACITY);
Semaphore fullSlots = new Semaphore(0);
Semaphore mutualExclusion = new Semaphore(1);void producer(){and for the consumer:
for(/*ever*/;;){
Object item = produceItem();
wait(emptySlots); // Wait for buffer space.
wait(mutualExclusion); // Enter critical section.
buffer.insertItem(item);
signal(mutualExclusion); // Leave critical section.
signal(fullSlots); // Signal the consumer.
}
}void consumer(){
for(/*ever*/;;){
wait(fullSlots); // Wait for item in buffer.
wait(mutualExclusion); // Enter critical section.
Object item = buffer.removeItem();
signal(mutualExclusion); // Leave critical section.
signal(emptySlots); // Signal the producer.
consumeItem(item);
}
}
What has gone wrong is that the OS has allocated only a single bit to record whether a signal was sent to the task. When task 1 sent two signals, the first signal set the bit; the second signal had no effect. Task 2 did not block when it performed its first wait (since the signal bit was set), but the fact that two signals were set has been lost; the second attempt to wait for a signal caused task 2 to block indefinitely.No. This wouldn't happen with semaphores. The semaphore counts the number of signals which have been received, so none are lost.
What is wrong is that only one philosopher gets to eat at any one time. It doesn't allow two philosophers at opposite sides of the table to both be eating.
It is 'unfair': a single task hogs the CPU. If the task never blocks, other tasks never get a chance to run. (Could be other tasks are more important.)
Efficiency is...useful-time ÷ total-timeWorst-case response time: Assume 20ms process has just completed its time-slice, and it must wait for its chance to come round again:
= (20 + 23 + 40 + 100) ÷ (20 + 3 + 23 + 3 + 40 + 3 + 100 + 3)
= 183 ÷ 195
= 93.8% (to 1 decimal place)3 + 23 + 3 + 40 + 3 + 100 + 3
= 172ms
= about a 6th of a second
[Requires wild guesswork. The students have been told what internal and external priorities are, but not many examples. Internal priorities are calculated (usually dynamically) by the scheduler. External priorities are determined explicitly by the creator of the process, either a human or parent process.]Criteria for internal priority:
- Amount of last quantum used
- Average % CPU usage so far
- # open files
Criteria for external priority:
- Whether the process belongs to the user or to the OS
- Importance of the user
- Whether the process is a background process or not
- How quickly the user wishes to see results
- Its deadline (in a soft real-time system)