Signal and Wait: Difference between revisions
 Yuron [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)m (1 revision imported) |
 W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
-->{{#invoke:Dependencies|add|Synchronisation,4|Atomicity,3|Mutual exclusion,3}} | -->{{#invoke:Dependencies|add|Synchronisation,4|Atomicity,3|Mutual exclusion,3}} | ||
<blockquote> | <blockquote> | ||
Beware: “signal” is used confusingly for somewhat | Beware: “signal” is used confusingly for somewhat different actions. This article is about synchronisation in [[Interprocess_Communication|interprocess communications]]. | ||
different actions. This article is about synchronisation in | |||
[[Interprocess_Communication|interprocess communications]]. | |||
For software-level exception – such as the user pressing ^C in | For software-level exception – such as the user pressing ^C in Unix – see [[Unix Signals|here]]. | ||
Unix – see [[Unix Signals|here]]. | |||
</blockquote> | </blockquote> | ||
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 [[Process_States|blocked]] if it tries to progress beyond some state where it depends on other processes … until any dependency has been resolved. | 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 [[Process_States|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 === | === Critical sections of code === | ||
Some sections of code should be [[Atomicity|atomic]] and may be protected by a “[[Mutual exclusion|mutex]]”. A [ | Some sections of code should be [[Atomicity|atomic]] and may be protected by a “[[Mutual exclusion|mutex]]”. A '''[[Monitoring]]''' contains the mutex and some ‘condition variables’. | ||
[[Image:signal_mutex.png|link=|alt=Signal wait on mutex]] | [[Image:signal_mutex.png|link=|alt=Signal wait on mutex]] | ||
An arriving process starts with a <strong><code>wait</code></strong> which may block progress, depending on the state of the condition variables – specifically if | An arriving process starts with a <strong><code>wait</code></strong> which may block progress, depending on the state of the condition variables – specifically if another process is in the critical section. | ||
another process is in the critical section. | |||
By becoming blocked (rather than in a ‘busy-wait’ loop) | By becoming blocked (rather than in a ‘busy-wait’ loop) there is an opportunity for the other process (or thread) to be able | ||
there is an opportunity for the other process (or thread) to be able | to exit the critical section. On exit, a <strong><code>signal</code></strong> is made which unblocks a waiting process (or thread). | ||
to exit the critical section. On exit, a <strong><code>signal</code></strong> is made which | |||
unblocks a waiting process (or thread). | |||
When referring to [[semaphores]]: | When referring to [[semaphores]]: | ||
| Line 31: | Line 25: | ||
=== [[Queues_Extra|Queuing]] === | === [[Queues_Extra|Queuing]] === | ||
If a process tries to read from an empty buffer it will have to wait | If a process tries to read from an empty buffer it will have to wait (block) – here sometimes known as <strong><code>sleep</code></strong>. It must stay in this state until there is something to read. | ||
(block) – here sometimes known as <strong><code>sleep</code></strong>. It must stay in this | |||
state until there is something to read. | |||
When a process inserts something into the buffer it needs to signal | When a process inserts something into the buffer it needs to signal (unblock) the waiting process – here sometimes known as <strong><code>wakeup</code></strong>. | ||
(unblock) the waiting process – here sometimes known as <strong><code>wakeup</code></strong>. | |||
[[Image:signal_queue.png|link=|alt=Signal wait on queue]] | [[Image:signal_queue.png|link=|alt=Signal wait on queue]] | ||
Similarly, if a process tries to write to a <em>full</em> buffer it will need | Similarly, if a process tries to write to a <em>full</em> buffer it will need to block until the creation of a space is signalled. | ||
to block until the creation of a space is signalled. | |||
<blockquote> | <blockquote> | ||
Do not confuse this with the “wait for a time to elapse | Do not confuse this with the “wait for a time to elapse ‘[[sleep]]’”, which is similar in some ways | ||
‘[[sleep]]’”, which is similar in some ways | but the ‘wakeup process’ is <em>elapsed time</em>, not an action from a specific process. | ||
but the ‘wakeup process’ is <em>elapsed time</em>, not an | |||
action from a specific process. | |||
</blockquote> | </blockquote> | ||
There is a [[Queues_Extra|more thoroughly described example here]]. | There is a [[Queues_Extra|more thoroughly described example here]]. | ||
==== Implementation ==== | ==== Implementation ==== | ||
There are some options open to the implementer. One example is <em>when</em> | There are some options open to the implementer. One example is <em>when</em> 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). | ||
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 <em>how</em> a signal is implemented. In the queue | Another question may be <em>how</em> 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 [[IO|I/O]] queue either the <code>put()</code> or <code>get()</code> process is probably an [[Interrupts|interrupt service routine]]. | ||
example (above), if a waiting process blocks, this is likely to be a [[scheduler]] call. Note that, with an [[IO|I/O]] queue either the <code>put()</code> or <code>get()</code> process is probably an [[Interrupts|interrupt service routine]]. | |||
---- | ---- | ||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Processes}} | {{Category|Processes}} | ||
Latest revision as of 10:22, 9 August 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 Monitoring 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.
