RTOS Interrupts - Protecting shared resources through resource guarding
overview
The foregoing explains how to solve the problem of competing access to shared resources between interrupts and interrupts, and between interrupts and tasks through critical sections and closing interrupts. Whether it is a critical area or a shutdown interrupt, there are side effects, and they will delay the system-related interrupt response. This section describes a way to protect shared resources from races with fewer side effects.
In Chapter B, we learned that, of course, this method is not only applicable to protecting shared resources by establishing a guardian task , but also protecting shared resources between interrupts by establishing a guardian interrupt .
Of course, whether it is a guardian interrupt\guard task, the essential idea is to establish a resource owner. When other interrupts and tasks want to access shared resources, they must initiate communication (request\notification), and then complete the shared resource through the resource owner. Access. After completing the access to the shared resource, the resource owner can choose whether to send the access result to the party requesting access to the resource:
Requirements and function analysis
This section is still based s_counton , adding Task2 as a resource owner (guard task) to complete access to shared resources. An example that demonstrates shared resource protection done through the resource owner.
Example Analysis
After running the example, whether the corresponding interrupt is triggered (connecting GPIO0 and GND) or the task Task1 sends a notification, their access to the shared variable is safe, and no one can interrupt anyone:
---receive form task, update