Other Parts Discussed in Thread: SYSBIOS
MessageQ_alloc eventually calls down to Task_restore which enables interrupts via Hwi_enable, regardless of the state of GIE at entry. Is this a bug? It's bad for composability.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Other Parts Discussed in Thread: SYSBIOS
MessageQ_alloc eventually calls down to Task_restore which enables interrupts via Hwi_enable, regardless of the state of GIE at entry. Is this a bug? It's bad for composability.
Hi Elron A Yellin,
Where is the call to Task_restore() that you are referring to?
It may help to know the versions of SYS/BIOS and IPC you are using.
Steve
SYSBIOS 6.35.4.50, IPC 1.25.2.12
MessageQ_alloc
GateMP_leave
xdc_runtime_IGateProvider_leave
ti_sdo_ipc_gates_GatePeterson_leave__E
xdc_runtime_IGateProvider_leave
ti_sysbios_gates_GateSwi_leave__E
Swi_restore
Task_restore
Thanks Steve,
Elron
Hi Elron,
I've searched through all of the IPC code and I am not seeing a call to Task_restore in MessageQ_alloc, or anywhere else in the IPC code.
Perhaps I am missing it. Could you show me where you are seeing that in the code?
Steve
Elron,
Yes, I was able to find it ... it's coming from the HeapMP_alloc call.
Furthermore, I've discussed with my colleague and the Hwi_disable/enable pair that's in Task_restore is there by design. It's needed because the call to Task_schedule (that's in Task_restore) could result in a Task context switch.
Lastly, since MessageQ_alloc blocks, it is expected that interrupts will be enabled upon return (and this assumption should be made for any function that blocks - interrupts will be enabled upon returning from the call to such a function).
Steve