Signal and Wait

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.

---

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Processes

About this resource • Atomicity • Containers • Context • Context Switching • Daemons • Fork Unix • Hypervisor • Idle • Interprocess Communication • Multi Threading • Mutual exclusion • Pipes • Pointer Arithmetic • Process Control Block (PCB) • Process Priority • Process Scheduling • Process States • Processes • Queues • Queues Extra • Race Conditions • Real Time • Resources • Scheduler • Signal and Wait • Sleep • Starvation • Synchronisation • Thrashing • Threads • Unix Signals