Differences between binary semaphores, mutex signals, and count semaphores

VxWorksSemaphores Mechanism Analysis

 

VxWorks semaphores are the optimal choice for inter-task communication, synchronization, and mutex, and the fastest communication between tasks. It is also the main means to provide synchronization and mutex between tasks. VxWorks provides three semaphores to solve different problems.

 

Binary semaphores: the fastest and most commonly used semaphores that can be used for synchronization or mutex.

Mutex semaphores: A special binary semaphores that are optimized to solve internal mutex problems such as priority inheritance, deletion security, and recursion.

Count semaphores: similar to binary semaphores, but changes with the number of semaphores released.

 

Binary semaphores

Binary semaphores can satisfy the mutual exclusion and synchronization between tasks, and require the minimum system overhead. Therefore, they are also called fast semaphores. A binary semaphore can be regarded as a flag, indicating whether the corresponding resource is available or unavailable. When a task calls semTake () to request a semaphore, if the semaphore is available at this time, the semaphore is cleared and the task continues to run immediately. If the semaphore is unavailable, the task is blocked to wait for the semaphore.

 

When a task calls semGive () to release a binary semaphore. If the semaphores are available, releasing them will not have any effect. If the semaphores are unavailable and no tasks are waiting to use them, the semaphores are simply set to available; if the semaphore is unavailable and one or more tasks are waiting for the semaphore,Tasks with the highest priority are deblocked,Semaphores are still unavailable.

 

Mutual Exclusion

When more than two tasks share resources such as the same memory buffer or the same I/O device, competition may occur.

 

Binary semaphores can lock shared resources to achieve efficient mutually exclusive access. Unlike the prohibition of interruption or preemption, binary semaphores are mutually exclusive only for access to associated resources, in addition, it provides more precise mutex granularity than the prohibition of interruption and preemption. When used, a binary semaphore is created to protect resources. The semaphore is available at the initial time.

 

When a task needs to access this resource, obtain the semaphore first, and all other tasks that want to access this resource will be blocked. When the task completes access to the resource, release the semaphore and allow other tasks to use the resource. Therefore, all operations that require mutual access to resources are implemented by semtake () and semgive.

 

Semtake (semmutex, wait forever)

In the critical section, only one task is accessed at a time.

Semgive (semmutex)

 

Synchronization

Another common usage of semaphores is the synchronization mechanism between tasks. In this case, semaphores represent the conditions or events that a task is waiting.Initially, semaphores are unavailable.A task or interrupt handler releases the semaphore to notify this event. Tasks waiting for the semaphore will be blocked until the event occurs and the semaphore is available. Once blocked, the task executes the appropriate event handler.The Application of semaphores in task synchronization is useful for freeing the interrupt service program from lengthy event processing to shorten the interrupt response time.

 

Mutex semaphores

Mutex semaphores are a special binary semaphores used to solve internal mutex problems: Priority Inheritance, deletion security, and recursive access to resources.

 

For general operating systems, mutex semaphores are usually binary flags, but vxwoks has extraordinary significance. Another typical example is that the Linux kernel also sets up mutex semaphores separately.

 

The difference between mutex semaphores and binary is:

① When defining a mutex semaphore, it is ready for use after initialization. It is only used for mutex;

② It can only be released by the task of taking (semtake (), that is, it is applied for by the same task and then released after use;

③ Because semtake and semgive are paired, they cannot be released in ISR (semgive ()).

 

Priority Inheritance

Priority inversion occurs when a high-priority task is forced to wait for an uncertain period of time and wait for a low-priority task to complete. VxWorks allows the use of Priority Inheritance algorithms and options in mutex semaphoresSEM-INVERSION-SAFEThe Priority Inheritance algorithm is enabled. The priority inheritance protocol ensures that tasks with resources are executed with the highest priority among all tasks on the resource, until it releases all of its semaphores, the task returns to the normal state. Therefore, this "inherited high-priority" task is not protected by any intermediate priority task.

 

Delete security

Another mutex problem involves task deletion. In a semaphore-protected critical section, it is often necessary to protect tasks executed in the critical section from accidental deletion. Deleting a task executed in the critical section may cause unexpected consequences, cause the semaphore to protect the resource to be unavailable, and cause the resource to be damaged, as a result, all other tasks to access the resource cannot be satisfied.

 

The primitive taskSafe () and taskUnsafe () provide a way to prevent tasks from being accidentally deleted. At the same time, mutex semaphores provide optionsSEM-DELETE-SAFEWith this option, taskSafe () is implicitly enabled when semTake () is called each time. When semGive () is called each time, taskUnsafe () is implicitly enabled, when a task receives a semaphore, it is protected against deletion.

 

Recursive Resource Access

Mutex semaphores can be obtained recursively. This means that the semaphores can be obtained multiple times before the semaphores are released. Recursion is useful for mutual calls but mutual access to a resource. This is possible because the system needs to track which task currently has a semaphore.

 

Counter semaphores

The counter semaphores are another means of implementing task synchronization and mutex, which are somewhat different in implementation. In addition to operating like a binary semaphore, counter semaphores also keep track of the number of semaphores released. Different from binary semaphores, the Count semaphores are released each time, and the counter increments by one. Each time they are obtained, the counter decreases by one. When the semaphores are reduced to 0, the tasks trying to obtain the semaphores are blocked.

 

Just like a binary semaphore, when a counting semaphore is released, if a task is blocked in the semaphore blocking queue, the task is unblocked; but if the semaphore is released, if no task is blocked on the semaphore blocking queue, add one to the counter.

 

Conclusion

From the analysis of the multi-task communication mechanism in the embedded operating system VxWorks, we can see that semaphores play an important role in the communication, synchronization and mutex between multiple tasks. Therefore, in-depth understanding and correct use of the VxWorks semaphore can improve the efficiency of multi-task communication in real-time systems.