Notes on Using the "SemaphoreMutualExclusion" Function

Restrictions for Use

NOTE: Improper use can result in the execution of one or more tasks being permanently stopped! Cycle time overruns and severe cycle time overruns may occur!

Observe the following.

The semaphores provided via the SemaphoreMutalExclusion function group may only be used in simple cases of "mutual exclusion" (mutual exclusion of access) to cover short sections of critical code (hereafter referred to as critical areas).

The functions may only be used by technical personnel familiar with the risks of semaphores and multitasking.

No holding of semaphores beyond the end of the task cycle:

The functions are only suitable for cases in which Take() and Give() are executed in the same cycle. It is not permitted to hold a semaphore beyond the end of an cycle (through Take()).

The functions may only be used in cases that are structured as follows:

// Code, which is not critical
   Take();
   // Do something critical. Should not take to long
   Give(); // No IF, ELSE or other conditions! Always execute Give()
// Code, which is not critical

The execution time of critical areas between Take() and Give() must be kept as short as possible.

Inverted access to semaphores is prohibited for the following reasons:

The inverted access Task1: Take(A), Take(B); Task2: Take(B), Take(A) to more than one semaphore can lead to a permanent block (Deadlock) of 2 or more tasks if the semaphores are not always reserved in the same order.

The inverted use of semaphores, in combination with the SEM_INVERSION_SAFE option results in a task keeping a higher priority (the priority of the task with the highest priority that is waiting for one of its semaphores) until it releases the last of the semaphores it is holding.

Using system functions or other functions within critical areas:

A task is not permitted to call up system functions in a critical area. For their part, the system functions could in turn use semaphores which could ultimately lead to the task maintaining an extremely high priority until it enables its last semaphore (see above regarding inverted use). Calling up any other functions should also be avoided because there is no guarantee that the functions are not internally using semaphores. This also applies to parameters of objects in the PLC configuration.