Why enable the interrupt so early on threadx scheduler on M4 port?

Question

On threadx M4 port of pendsv interrupt implementation, which do the actual context switch of the multithread support of threadx, it shows all the during the procedure, the interrupt all opened without disabled like other rtos, like ucos, rtthread, etc, so is this cause somethings that unpredictable at running time ?

like below code, the "cpsie i" was executed before the next ready to run thread restored

the line 202 eanbled the interrupt, but the actual context swithc has not finished yet, this is not like ucos does on m4 port, why is this safe? thank you!

**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!

Answer 1

ThreadX is designed to run as fast as possible and minimize critical sections. Enabling interrupt before restoring context is safe.

More details:
The scheduler is running in the PendSV interrupt, only an interrupt with higher priority than the PendSV can preempt the scheduler. The PendSV cannot preempt itself. ThreadX does not call the scheduler directly(except the first time). So, there is no re-entrancy for the scheduler. The context restoring process can be interrupted by a higher priority interrupt, the hardware will take care of interrupt nesting and saving/restoring caller saved registers etc. When the high priority interrupt is returned, the context restoring process continues as if nothing happened. If a high priority interrupt makes another higher priority thread ready, ThreadX will record the new thread as next thread to execute, but it will not call the scheduler directly. Instead, it sets the PendSV interrupt to pending state. Another context switch happens after the current context restoring process is finished. As other interrupts do not affect the process of restoring context, it is safe to enable interrupt during context restore process. By enabling interrupt earlier, other interrupts can be served with less delay. It is better to have less time in interrupt disabled state.

Answer 2

The short answer is that it's safe because beyond that point the system can handle an interrupt without leaving its critical data structures in an inconsistent state.

More specifically, after that point ThreadX's internal data structures are in a consistent state such that an ISR can invoke permitted ThreadX services safely - whereas before that point they are not, and so ISRs must be prevented from running.

Note that the M4's exception system - especially the SVCall, PendSV and interrupt exceptions and their relative priorities - facilitates implementation of a preemptive multitasking system without requiring explicit disabling and enabling of interrupts at all.