IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

can potentially interrupt execution of Task_B, or visa-versa, depending on the assigned priorities. Consider
the case where priority of Task_A is lower (higher numerically) than priority of Task_B, such that Task_B
can preempt Task_A. This case can lead to execution of the Surprised_to_be_Here() function under the
following circumstances.
Let us say that Task_A has already executed 0xFFFE times and on its 0xFFFF'th execution it is preempted
by Task_B at the indicated "Sensitive" point immediately after executing the ADD opcode which increments
the lower half of the 32 bit up counter. At this exact point, the My_Ticker value will read zero due to the
carry from the lower 16 bits not yet being applied to the upper half word. And thus Task_B lands in the
Surprised_to_be_Here() function when it encounters the half updated My_Ticker reading.
Protecting Critical Sections
Three methods for protecting critical sections are presented here.
1) Semaphore
2) Interrupt Masking
3) RTOS Task Switch Lock
Each method has its advantages and limitations, which are summarized at the end of this discussion. The
choice of which method to use will depend on the design situation.
Semaphore Protection
A common way to protect critical sections is with the use of semaphores. The @Chip-RTOS provides
resource semaphores which provide a mutually exclusive access to a resource or data object.
The example defective code from Figure 3 above can be corrected with the use of a resource
semaphore as shown below.
static unsigned long My_Ticker = 1 ;
void huge Task_A(void)
{
RTX_Reserve_Sem(semID, 0) ;
if (My_Ticker < 0x7FFFFFFFL)
{
My_Ticker++ ;
}
RTX_Release_Sem(semID) ;
}
void huge Task_B(void)
{
unsigned long ticker ;
RTX_Reserve_Sem(semID, 0) ;
ticker = My_Ticker ;
RTX_Release_Sem(semID) ;
if (ticker == 0)
Page 227 / 400