Signal and Wait: Difference between revisions
pc>Yuron No edit summary |
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
(No difference)
|
Revision as of 12:46, 26 July 2019
On path: IPC | 1: Processes • 2: Interprocess Communication • 3: Shared Memory • 4: Files • 5: Unix Signals • 6: Pipes • 7: Sockets • 8: Synchronisation • 9: Synchronisation Barrier • 10: Atomicity • 11: Mutual exclusion • 12: Signal and Wait |
---|
Depends on | Synchronisation • Atomicity • Mutual exclusion |
---|
Beware: “signal” is used confusingly for somewhat different actions. This article is about synchronisation in interprocess communications. For software-level exception – such as the user pressing ^C in Unix – see here.
There are various cases where a process should not proceed until something else has happened. Different examples sometimes use different terminology, but the principles are basically the same. The point is that a process may become blocked if it tries to progress beyond some state where it depends on other processes … until any dependency has been resolved.
Critical sections of code
Some sections of code should be atomic and may be protected by a “mutex”. A [Monitor monitor] contains the mutex and some ‘condition variables’.
An arriving process starts with a wait
which may block progress, depending on the state of the condition variables – specifically if
another process is in the critical section.
By becoming blocked (rather than in a ‘busy-wait’ loop)
there is an opportunity for the other process (or thread) to be able
to exit the critical section. On exit, a signal
is made which
unblocks a waiting process (or thread).
When referring to semaphores:
- the wait call is P (sometimes laboriously translated as “Procure”)
- the signal call is V (sometimes laboriously translated as “Vacate”)
Queuing
If a process tries to read from an empty buffer it will have to wait
(block) – here sometimes known as sleep
. It must stay in this
state until there is something to read.
When a process inserts something into the buffer it needs to signal
(unblock) the waiting process – here sometimes known as wakeup
.
Similarly, if a process tries to write to a full buffer it will need to block until the creation of a space is signalled.
Do not confuse this with the “wait for a time to elapse ‘sleep’”, which is similar in some ways but the ‘wakeup process’ is elapsed time, not an action from a specific process.
There is a more thoroughly described example here.
Implementation
There are some options open to the implementer. One example is when to signal – every time or just when something is waiting? The first choice is simpler (no need to check) but may send signals when they are not required (they must be ignored).
Another question may be how a signal is implemented. In the queue
example (above), if a waiting process blocks, this is likely to be a scheduler call. Note that, with an I/O queue either the put()
or get()
process is probably an interrupt service routine.