- Asynchronous device driver where we are dealing with slow devices. We don’t necessarily want tasks blocked waiting on the device.
- At system start-up, many RTOSs start tasks as active (ready to run). We may have an ordering dependency for execution (e.g. initialisation of global resources) where all tasks must wait for a given condition (the concept of a barrier which can be very important in multi-processor systems).
- Having a managed task abort notification, rather than deleting tasks (which can lead to resource issues). Similar in concept to the UNIX/Linux kill signal. Also used to manage task pools.
- the relation that exists when things occur at the same time; “the drug produces an increased synchrony of the brain waves” [syn: synchronism] [ant: asynchronism]
- an adjustment that causes something to occur or recur in unison [syn: synchronization]
- coordinating by causing to indicate the same time; “the synchronization of their watches was an important preliminary” [syn: synchronization]
It should be noted that synchronisation and mutual exclusion often get lumped together and confused. Mutual exclusion is about making sure thing don’t happen at the same time, whereas synchronisation is about making sure they do.
In regard to task synchronisation there four classes of interaction we need to address:
- one-to-one – only two task synchronising
Initially we address the condition where only two tasks are synchronising.
- Task2 runs until it reaches the synchronisation point as defined by an RTOS synchronisation object (SO), at which point it waits for Task1
- Task1 now runs and reaches the synchronisation point, signals Task2 via the SO. Both tasks are now ready to run.
- The higher priority task now continues execution and the lower priority task is made ready (If the tasks are of equal priority typically Task1 will continue as this avoids a context switch).
We can now say that Task1 and Task2 have synchronized their threads of execution.
- Symmetric or Bilateral Synchronisation
- Asymmetric or Unilateral Synchronisation
- if Task2 arrives at the SO first it will wait for Task1, and then synchronisation with Task1 when it arrives
- if Task1 arrives at the SO first it will not wait for Task2, thus unilateral synchronisation.
However, we have yet another dichotomy; does Task2 consumes the signal Task1 has set (auto-reset) or does Task1 clear the signal (manual-reset) at some later time.
Finally, in the consuming model what happens if Task1 signals the SO more than once before Task2 arrives at the synchronisation point, and therefore the original signal has not been consumed? One model is there is no effect, the signal remains set and is consumed when Task2 arrives (binary model). The alternative is that a count is kept of the number of signals set by Task1. Each time Task2 waits on the SO this count is decremented, and Task2 will only block if the count is zero.
So we can classify RTOS synchronisation into the following:
In the next posting I shall be looking at synchronisation involving more than two tasks and then following that one by examining some actual RTOSs and their support for synchronisation.
Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking.
His current interest lie in IoT Security and Agile for Embedded Systems.
Latest posts by Niall Cooling (see all)
- Using a Raspberry Pi as a remote headless J-Link Server - July 4, 2019
- Peripheral register access using C Struct’s – part 1 - January 24, 2019
- An Introduction to Docker for Embedded Developers – Part 5 Multi-Stage Builds - October 11, 2018