ThreadX kernel enter function

Question

What does the ThreadX kernel enter function do?

What does it mean that this function does not return?

How are the threads created in the tx_application_define function scheduled and executed?

Answer 1

ThreadX kernel-enter routine performs the following:

1. If ThreadX initialization needs to take place:

   • Call any port specific pre-processing.

   • Invoke the low-level initialization to handle all processor specific initialization issues.

   • Invoke the high-level initialization to exercise all of the ThreadX components.

   • Call any port specific post-processing.

2. Call the user-provided initialization function tx_application_define.

3. Call any port specific pre-scheduler processing.

4. Enter the scheduling loop to start executing threads.

---

To answer your questions:

• In step #2, the ThreadX kernel-enter routine calls function tx_application_define, which is up to you to implement. It is pretty similar in essence to a user-callback routine, except for the fact that it is not provided as a function-pointer (i.e., the tx_application_define symbol is resolved during link-time instead of during runtime). This function is where you should typically create all the threads.

• In step #4, the ThreadX kernel-enter routine starts an infinite loop, which is in essence the scheduler itself. This is where all the context switches are managed, and the threads go in and out of execution. Upon every HW interrupt, the PC (program-counter) jumps from the currently executing thread to the IV (interrupt-vector), and from there to the connected ISR (interrupt-service-routine). After that, it jumps back to the scheduler (i.e., into the infinite loop), which determines whether a context-switch is required or not. Execution eventually returns to the last executing thread or to some other thread, depending on the scheduler decision.

• As you can understand, every context-switch is the result of a HW interrupt, but not every HW interrupt results with a context-switch. You should typically refrain from enabling the interrupts (by calling function __enable_interrupt from within function tx_application_define), as the ThreadX kernel-enter routine makes sure of that just before it enters the scheduling loop.