patternMinor
Hoare's monitor - what happens after a "signal"
Viewed 0 times
aftersignalwhatmonitorhappenshoare
Problem
Assume I have producer and consumer in a monitor.
-
The code of the consumer signals the producer and then does something else.
I know in a Hoare-style monitor, after signaling, the thread that is signaled wakes up and is is now schedule.
What about the other instructions in the consumer after the signal? When will the consumer continue?
-
What if the consumer sends the signal before the producer does the wait? Will the producer be stuck forever?
-
If there is a context switch will the mutex of the monitor be released?
-
The code of the consumer signals the producer and then does something else.
I know in a Hoare-style monitor, after signaling, the thread that is signaled wakes up and is is now schedule.
What about the other instructions in the consumer after the signal? When will the consumer continue?
-
What if the consumer sends the signal before the producer does the wait? Will the producer be stuck forever?
-
If there is a context switch will the mutex of the monitor be released?
Solution
Here's the picture of a Hoare-style monitor from wikipedia user Theodore.norvell:
-
The circles are threads, the rooms off to the sides are various queues. Think of the monitor as being protected by a mutex. Only one thread gets the mutex at a time. Once a thread has the mutex it keeps the mutex until it releases the mutex by (1) waiting (in which case it goes to sleep on a condition variable), (2) signalling (in which case it goes into the queue labeled
-
If the consumer sends the signal before the producer waits then the producer will be stuck forever. This is sometimes called "the missed wakeup problem." It is avoided by recognizing that you should really be waiting for some condition to become true (e.g., "the queue is no longer full"), not waiting for some condition variable to get signaled. When the producer is in the monitor (has acquired the mutex) it only waits on the condition variable if it sees that the condition is not currently true. The consumer signals the condition variable every time the condition (state) "queue is full" changes to "queue is not full", whether there is anyone waiting on the condition variable or not.
-
If there is a context switch the mutex of the monitor will not be released.
-
The circles are threads, the rooms off to the sides are various queues. Think of the monitor as being protected by a mutex. Only one thread gets the mutex at a time. Once a thread has the mutex it keeps the mutex until it releases the mutex by (1) waiting (in which case it goes to sleep on a condition variable), (2) signalling (in which case it goes into the queue labeled
s in the picture or (3) exiting the monitor completely. The scheduling algorithm is given in the wikipedia article. At any point in time the relative priorities to get into the monitor are: (1) the single thread that was most recently signalled, (2) threads in queue s (usually s is FIFO), (3) threads in queue e (the entry queue).-
If the consumer sends the signal before the producer waits then the producer will be stuck forever. This is sometimes called "the missed wakeup problem." It is avoided by recognizing that you should really be waiting for some condition to become true (e.g., "the queue is no longer full"), not waiting for some condition variable to get signaled. When the producer is in the monitor (has acquired the mutex) it only waits on the condition variable if it sees that the condition is not currently true. The consumer signals the condition variable every time the condition (state) "queue is full" changes to "queue is not full", whether there is anyone waiting on the condition variable or not.
-
If there is a context switch the mutex of the monitor will not be released.
Context
StackExchange Computer Science Q#13416, answer score: 4
Revisions (0)
No revisions yet.