Programming embedded techniques: RTOS – mutual exclusion

This lesson focuses on source sharing among concurrent threads and the mutual exclusion mechanisms offered in the RTOS for protecting this sort of shared methods.

The matter of this last lesson on Real-Time Running Systems (RTOS) is useful resource sharing among concurrent threads and the mutual exclusion mechanisms offered in the RTOS for guarding this sort of shared resources.

Lesson 28 RTOS Portion-7: Mutual exclusion mechanisms

https://www.youtube.com/look at?v=kcpVI3IjUUM

Shared-Point out Concurrency

The most straightforward and most often applied way for concurrent threads to talk is by sharing memory and other methods like the hardware peripherals (e.g., GPIO registers in the video). Even so, the video illustrates how this sort of shared-point out concurrency can guide to race conditions and other conflicts among the threads competing for the similar means below a preemptive RTOS.

Mutual Exclusion

The terrible information is that the RTOS does not know or treatment about shared sources in your threads, so the burden of identifying each last shared source and stopping concurrency dangers about it is fully on you, the application developer. Specifically, you need to guarantee that only just one concurrent thread (or interrupt) can accessibility any resource at a time. This variety of access control is termed mutual exclusion, and the excellent information is that RTOSes offer a entire assortment of mutual exclusion mechanisms.

Essential Part

The mutual exclusion mechanism you presently know from lesson 19 about race disorders is disabling interrupts right before accessing a shared useful resource and re-enabling them right away just after. The part of code where by interrupts remain disabled is called a critical segment.

Even so, in the presence of an RTOS, you need to be careful to use the significant portion system reliable with the RTOS and its interrupt disabling policy, as proven in the movie.

A crucial segment is an productive, non-blocking mutual exclusion mechanism but should really only be utilised for extremely brief accessibility to a shared source. This is also the only mechanism for safeguarding assets shared between threads and interrupts.

Scheduler Lock

Scheduler lock is another non-blocking mutual exclusion system consisting of locking the RTOS scheduler ideal in advance of accessing a shared source and unlocking it afterward. Scheduler lock stops re-scheduling the at the moment running thread, even if increased-precedence threads are ready.

Most RTOSes give a very simple, unconditional scheduler lock that has an effect on all threads indiscriminately. Some RTOSes, this sort of as QXK shown in the video, provide a selective scheduler lock, which prevents only threads up to a provided priority ceiling.

Scheduler lock, specially the selective lock, is an efficient mutual exclusion system, which is also immune to the unbounded priority inversion explained under. The only limitation is that a thread will have to not block while holding the lock.

Semaphore

In the last lesson about semaphores, I mentioned that they ended up initially conceived to protect shared assets but are unsafe in priority-based devices. In today’s online video, you see the dilemma identified as unbounded priority inversion. In this predicament, a medium-priority thread, unrelated to the shared source, retains jogging as prolonged as it desires to, though substantial-priority thread blocks on a semaphore held by a small-priority thread.

Mutex

Mutex is the most subtle, blocking mutual-exclusion system comparable to a binary semaphore but specially developed to stay clear of unbounded precedence inversion [1]. The video clip demonstrates a priority-ceiling mutex, which must be explicitly configured with the ceiling precedence (at minimum as large as the priority of the highest-priority thread contending for the safeguarded resource).

The online video also explains an substitute priority-inheritance mutex, which immediately boosts the thread priories, but at the charge of a lot more context switches and extended delays of large-priority threads.

Finish Notes

Mutual exclusion has several far more detrimental implications over and above these described in the video [2]. For example, aside from the preventable unbounded precedence inversion, every single mutual exclusion system triggers bounded precedence inversion, in which a high-precedence thread are unable to run due to the fact a decreased-priority thread nonetheless takes advantage of a shared resource. For that explanation, mutual exclusion interferes with true-time functionality and complicates any schedulability analysis, these kinds of as RMA/RMS.

In the finish, mutual exclusion is 1 of people complications that may be far better prevented than solved [3]. The shared-state concurrency design is no more time the only option on the market. The 1990s introduced alternative genuine-time concurrency architectures that avoid useful resource sharing and hence reduce the need for sophisticated mutual-exclusion mechanisms. I will converse about these additional modern-day ways in future lessons.

[1] Michael Barr, Mutexes and Semaphores Demystified, Barr Team, 2016

[2] Michael Barr, The Perils of Preemptive Multitasking, Barr Group, 2006

[3] Edsger W. Dijkstra, Magnificence and Successful Reasoning, 1996

---

Dr. Miro M. Samek is the creator of the open resource QP actual-time embedded frameworks and the freeware QM graphical product-primarily based layout instrument. He is also the founder and CEO of Quantum Leaps — the service provider of contemporary embedded software centered on energetic objects and hierarchical point out equipment as effectively as tools for visible modeling, automated code generation, and unit screening of deeply embedded software program. Miro teaches the well known YouTube “Modern Embedded Techniques Programming” movie course on which this article collection is based mostly.

---

Linked Contents: