Closed carll00226 closed 1 year ago
Hi @carll00226 - I believe you've found a bug. ThreadX should definitely be calling TX_RESTORE at some point. I will file an internal bug report and look into this. Thanks!
By default, TX_NOT_INTERRUPTABLE is not defined. You can define it for smaller code size and faster execution at the expense of longer interrupt lock out times. Whether it is defined or not, ThreadX still disables interrupts in critical sections.
Is there a reason you have it defined?
Hi, scott: We define it for faster execution, but as a result the improvement is not obvious. and we dont't know how much the effect is on interrupt lock time.
Hi @carll00226 - this should now be fixed in v6.2.0_rel. See updated file here: https://github.com/azure-rtos/threadx/blob/master/common_smp/src/tx_thread_create.c#L352 Let me know if that works for you.
Hi, Scott: I am using common_smp and define TX_NOT_INTERRUPTABLE, when I create task B in task A, A will call _tx_thread_create, and in file tx_thread_create.c ,line 229 is TX_DISABLE as code1. and then goto line 292 to call _tx_thread_system_ni_resume as code2. and then it will return to task A after executing _tx_thread_system_resume, but no one will call TX_RESTORE during the resume process. so when returned to A, it cannot response to IRQ. And it is OK if I undefine TX_NOT_INTERRUPTABLE. So what's the problem? Should any one call TX_RESTORE if defined TX_NOT_INTERRUPTABLE?
<code 1>: ` / Prepare to make this thread a member of the created thread list. / 229: TX_DISABLE
<code 2>: ` / Determine if an automatic start was requested. If so, call the resume thread function and then check for a preemption condition. / if (auto_start == TX_AUTO_START) {
ifdef TX_NOT_INTERRUPTABLE
292: _tx_thread_system_ni_resume(thread_ptr);
else
endif`