View source for OCEOS/oceos inter-task communication

=<span style="color:#0000ff">'''Synchronization and Inter-task Communication'''</span>=
Many data structures cannot be fully accessed with a single instruction. Errors can result if a job using such a structure is pre-empted by another job that also uses the structure.<br>
To address this OCEOS provides up to 63 mutual exclusion semaphores [[OCEOS/oceos inter-task communication/mutex|mutexes]]. Each shared data structure or critical code segment typically is associated with its own mutex.<br>
Any job that uses a shared item should first acquire its mutex from OCEOS, and when finished with the item return the mutex. The number of instructions for which the mutex is held must be finite.<br>
OCEOS allows a mutex be held by only one job at any one time. A job that uses a shared data structure or critical code segment can use an associated mutex to exclude all other jobs.
<blockquote style="background-color: #c6e2f7; border-left-style: solid; border-left-width: 3px; border-left-color: blue; "> '''Note'''<br>
An OS does not prevent a shared resource being accessed if no attempt is made to acquire its mutex. The software developer must ensure this is done before the shared resource is used.
</blockquote>

OCEOS provides two types of inter-job communication, counting semaphores and data queues. Semaphores and data queues are handled by OCEOS in a way different to many other OS.<br>
In most OS a job that waits on a zero semaphore or tries to read an empty data queue may be blocked at that point and wait there indefinitely or with an optional timeout.<br>
In OCEOS an active job may be pre-empted but cannot otherwise be blocked, so three options are provided in case a counting semaphore is zero when waited on or a data queue is empty when read:<br>
# One option results in a value always being returned and the job continuing. The returned value will indicate that the semaphore was zero or queue empty, and the job can take this into account.
# In the other options, if the semaphore is zero or queue empty the job terminates and will restart from its beginning when the semaphore is signalled or queue written, or after an optional timeout.
# When the job becomes active again after a timeout and again encounters the second option the behavior is as with the first option, the job continues and takes into account that a timeout has occurred.
<blockquote style="background-color: #c6e2f7; border-left-style: solid; border-left-width: 3px; border-left-color: blue; "> '''Note'''<br>
Because a job restarts when a resource becomes available rather than waiting at the point where it sought the resource any local data developed up to that point will be lost unless stored non-locally for use after the restart. <br>
If required this can be done using static variables or structures, or using data queues or counting semaphores.
</blockquote>
'''In OCEOS event communication between tasks or between tasks and interrupt handlers is done typically by using counting semaphores.'''

*[[OCEOS/oceos_inter-task_communication/mutex| OCEOS Mutexes]]
*[[OCEOS/oceos_inter-task_communication/dataq| OCEOS Data Queues]]
*[[OCEOS/oceos_inter-task_communication/semaphore| OCEOS Counting Semaphores]]
[[Category:backup]]