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

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.