0

在pendsv中断实现的threadx M4端口上，它做threadx多线程支持的实际上下文切换，它显示了所有的过程，中断都像其他rtos一样打开而没有禁用，比如ucos，rtthread等，所以是这样导致运行时无法预测的事情？

像下面的代码一样，“cpsie i”在下一个准备运行的线程恢复之前执行

202行允许中断，但是实际的上下文swithc还没有完成，这不像ucos在m4端口上做的，为什么这样安全？谢谢你！

**202     CPSIE   i**                                       @ Enable interrupts
203 @         
204 @    /* Increment the thread run count.  */
205 @         
206 __tx_ts_restore:
207     LDR     r7, [r1, #4]                            @ Pickup the current thread run count
208     LDR     r4, =_tx_timer_time_slice               @ Build address of time-slice variable
209     LDR     r5, [r1, #24]                           @ Pickup thread's current time-slice
210     ADD     r7, r7, #1                              @ Increment the thread run count
211     STR     r7, [r1, #4]                            @ Store the new run count
212 @         
213 @    /* Setup global time-slice with thread's current time-slice.  */
214 @         
215     STR     r5, [r4]                                @ Setup global time-slice
216           
217 #ifdef TX_ENABLE_EXECUTION_CHANGE_NOTIFY
218 @         
219 @    /* Call the thread entry function to indicate the thread is executing.  */
220 @         
221     PUSH    {r0, r1}                                @ Save r0/r1
222     BL      _tx_execution_thread_enter              @ Call the thread execution enter function
223     POP     {r0, r1}                                @ Recover r3
224 #endif    
225 @         
226 @    /* Restore the thread context and PSP.  */
227 @         
228     LDR     r12, [r1, #8]                           @ Pickup thread's stack pointer
229     LDMIA   r12!, {LR}                              @ Pickup LR
230 #ifdef TX_ENABLE_FPU_SUPPORT
231     TST     LR, #0x10                               @ Determine if the VFP extended frame is present
232     BNE     _skip_vfp_restore                       @ If not, skip VFP restore 
233     VLDMIA  r12!, {s16-s31}                         @ Yes, restore additional VFP registers
234 _skip_vfp_restore:
235 #endif    
236     LDMIA   r12!, {r4-r11}                          @ Recover thread's registers
237     MSR     PSP, r12                                @ Setup the thread's stack pointer
238 @         
239 @    /* Return to thread.  */
240 @         
241     BX      lr                                      @ Return to thread!
4

2 回答 2

2

ThreadX 旨在尽可能快地运行并最大限度地减少关键部分。在恢复上下文之前启用中断是安全的。

更多细节：
调度器在 PendSV 中断中运行，只有优先级高于 PendSV 的中断才能抢占调度器。PendSV 不能抢占自己。ThreadX 不直接调用调度器（第一次除外）。因此，调度程序没有重入。上下文恢复过程可以被更高优先级的中断中断，硬件将负责中断嵌套和保存/恢复调用者保存的寄存器等。当返回高优先级中断时，上下文恢复过程继续进行，就好像什么都没发生一样。如果一个高优先级的中断使另一个更高优先级的线程准备好，ThreadX 会将新线程记录为下一个要执行的线程，但不会直接调用调度程序。相反，它将 PendSV 中断设置为挂起状态。在当前上下文恢复过程完成后会发生另一个上下文切换。由于其他中断不影响上下文恢复过程，因此在上下文恢复过程中开启中断是安全的。通过更早地启用中断，可以以更少的延迟处理其他中断。中断禁用状态的时间最好少一些。

于 2020-07-16T20:56:36.460 回答
1

简短的回答是它是安全的，因为超过这一点，系统可以处理中断，而不会使其关键数据结构处于不一致状态。

更具体地说，在此之后 ThreadX 的内部数据结构处于一致状态，这样 ISR 可以安全地调用允许的 ThreadX 服务 - 而在此之前它们不是，因此必须阻止 ISR 运行。

请注意，M4 的异常系统——尤其是 SVCall、PendSV 和中断异常及其相关优先级——有助于实现抢占式多任务系统，而根本不需要显式禁用和启用中断。

于 2020-07-16T10:43:43.293 回答