INTER-PROCESS COMMUNICATION AND SYNCHRONISATION:

shared data problem

/* becomes an integral/atomic action */

Solving the Shared Data Problem

Disable interrupts whenever your task code uses the shared data. Atomic Code - is safe A part of a program is said to be atomic if it cannot be interrupted. When we disable interrupts around the lines of the task code that uses the shared data, we have made that collection of lines atomic, Critical Section A sequence of instructions that must be made atomic (for the system to work properly) is often called a critical section.

Interrupt Latency
The following factors control interrupt latency and, therefore response.
1. Disable Time = the longest period of time during which interrupts are disabled. 2. Overhead = how long it takes the microprocessor to stop what it is doing, do the necessary bookkeeping, and start executing the first instruction of the interrupt routine.

Interrupt Latency (cont)

3. Response time = how long it takes the interrupt routine to save the context and then do enough critical work to respond to the interrupt. 4. Priority Delay = the period of time it takes to execute any interrupt routines for interrupts that are of higher priority than the one in question.

semaphores

RTOS semaphores
Most RTOS normally use the paired terms take and release. Other RTOS paired terms may be get-give, pend-post, waitsignal. Tasks can call two RTOS functions, TakeSemaphore and ReleaseSemaphore. If one task has called Take-Semaphore to take the semaphore and has not called ReleaseSemaphore to release it, then any other task that calls TakeSemaphore will be blocked until the first task calls ReleaseSemaphore. Only one task can have the semaphore at a time.

Tank monitoring system

Imagine I have 300 watering tanks in my greenhouse I have one microprocessor that constantly monitors the water level at every single tank. It takes a while to determine the water level for each tank. Whenever I press a button I want to immediately know the water level for a particular tank.

void vRespondToButton (void) /* "Button Task" - High priority */ { !! Block until user pushes a button i = !! Get ID of button pressed TakeSemaphore (); tankdata[i].ITimeUpdated, tankdata[i].ITankLevel); ReleaseSemaphore (); } void vCalculateTankLevels (void) /* "Levels Task" - Low priority */ { TakeSemaphore (); !! Set tankdata[i].ITimeUpdated !! Set tankdata[i].ITankLevel ReleaseSemaphore (); (...) }

Semaphore Variants Counting semaphores semaphores that can be taken multiple times. Resource semaphores useful for the shared-data problem. Mutex semaphore automatically deal with the priority inversion problem.

Reentrancy
A reentrant function can be interrupted at any time and resumed at a later time without loss of data. A reentrant function can be used by more than one task without fear of data corruption. That is, more than one instance of it can be concurrently invoked and executed. One way to avoid the shared data problems is to allow access to shared data only among reentrant functions.

Deadlock
A deadlock, also called a deadly embrace, is a situation in which two tasks are each unknowingly waiting for resources held by the other.
Assume task T1 has exclusive access to resource R1 and task T2 has exclusive access to resource R2. If T1 needs exclusive access to R2 and T2 needs exclusive access to R1, neither task can continue. They are deadlocked.