...
The mutual exclusion mechanism used depends on how fast the code will access a shared resource, as shown in the table below.
| Panel |
|---|
|
| Resource Sharing Method | When should you use? | | Disable/Enable Interrupts | When access to shared resource is very quick (reading from or writing to few variables) and access is faster than µC/OS-III’s interrupt disable time.
It is highly recommended to not use this method as it impacts interrupt latency. | | Locking/Unlocking the Scheduler | When access time to the shared resource is longer than µC/OS-III’s interrupt disable time, but shorter than µC/OS-III’s scheduler lock time.
Locking the scheduler has the same effect as making the task that locks the scheduler the highest-priority task.
It is recommended not to use this method since it defeats the purpose of using µC/OS-III. However, it is a better method than disabling interrupts, as it does not impact interrupt latency. | | Semaphores | When all tasks that need to access a shared resource do not have deadlines. This is because semaphores may cause unbounded priority inversions (described later). However, semaphore services are slightly faster (in execution time) than mutual-exclusion semaphores. | | Mutual Exclusion Semaphores | This is the preferred method for accessing shared resources, especially if the tasks that need to access a shared resource have deadlines.
µC/OS-III’s mutual exclusion semaphores have a built-in priority inheritance mechanism, which avoids unbounded priority inversions.
However, mutual exclusion semaphore services are slightly slower (in execution time) than semaphores since the priority of the owner may need to be changed, which requires CPU processing |
|