Other Parts Discussed in Thread: CC2652RB
We are trying to make sure that our application is thread-safe, and have a couple questions concerning the execution path between threads under certain circumstances. I've consulted the SYS/BIOS (TI-RTOS Kernel) User's Guide and I'm still not clear.
- Let's say that I have TaskA with priority level 2, and TaskB with priority level 4. TaskB runs until it pends a semaphore, and is now BLOCKED. TaskA was READY, and is now RUNNING as it is the next-highest priority thread. A SWI is posted, which runs immediately due to being enabled and higher priority than any task, even though TaskA remains in the RUNNING state during the SWI function execution.
- Question: If the SWI posts the semaphore that TaskB is pending, when the SWI completes, will execution return to TaskA and leave TaskB READY until another Task/Semaphore/etc function is called in TaskA that would cause a context switch to the higher-priority TaskB, OR, would the posting of the semaphore in the SWI cause that context switch and TaskB would pre-empt returning to TaskA from the SWI?
- We were under the impression that context switches to another higher priority task would only take place when the current RUNNING thread encountered a TI-RTOS-specific Task_x(), Semaphore_x(), Mailbox_x(), etc function, but the SYS/BIOS (TI-RTOS Kernel) User's Guide (Rev. V), in section 3.6.2 Task Execution States and Scheduling (pg 85) also states the following: "The running task becomes Task_Mode_BLOCKED when it calls a function (for example, Semaphore_pend() or Task_sleep() ) that causes the current task to suspend its execution; tasks can move into this state when they are performing certain I/O operations, awaiting availability of some shared resource, or idling."
- Question: Can you elaborate on these "certain I/O operations"? Does this mean that using PIN/GPIO driver functions could also cause a context switch just like pending a semaphore? Or what does this mean?
