Synchronization and messaging provides the necessary communication between tasks in one system to tasks in another system. The event flag is used to synchronize internal activities while message queues and mailboxes are used to send text messages between systems. Common data areas utilize semaphores. Below are top 3 messaging and synchronization techniques.
These are independent kernel objects that are designed to offer flagging mechanisms required to control access to resources. There are two types of semaphores; counting semaphores that feature a random number of states and binary semaphores that feature two states. Binary semaphores can be classified as counting semaphores that have a count limit of 1. Tasks attempt to obtain semaphores in order to access their required resources. The obtains can only succeed if semaphore value is greater than 0. In RTOS tasks can make blocking calls in order to obtain a semaphore; tasks can be suspended until their required semaphore is released by another task. A release increments the semaphores value and vice versa.
Mailboxes also referred to as exchanges are independent kernel objects that facilitate transfer of messages by tasks. The message sized may be fixed or determined by the implementation. Pointers to complex data are sent through mailboxes. As such, some kernels make use of mailboxes in order to store data in a regular variable where kernel can access it with ease. If a task sends messages to a full mailbox, it receives an error message. To prevent this, RTOS supports blocking calls to ensure that messages are suspended until the mailbox is read by another task to create room for more messages. Once a task reads from a mailbox, it renders it empty such that, if a task tries to read from the mailbox, it gets an error message and is suspended until the mailbox is filled. Some RTOSes have a broadcast feature that allows a message to be sent to all suspended tasks upon reading a particular mailbox.
Queues are also independent kernel objects whose aim to provide means for tasks to transfer messages. They are deemed more complex but flexible as compared to mailboxes, their message size may be fixed, pointer oriented and based on the implementation. A task may send to a queue until the queue is full. Queue depths are mainly user specified during creation or configuration. RTOS supports block calling meaning that, if a queue is full, a task is put on hold until the queue is read by other tasks in the same order as the message were sent; first in, first out. If tasks try to read from an empty queue, it receives an error message until the queue is filled by another task.
Though tasks can be totally isolated from other tasks, the synchronization and communicationrequirement between tasks is quite common. So, despite tasks having a degree of independence, they are aware of other tasks.