About the reasons for setting the timer-internal thread with the THREADOBJ_IRQCONTEXT flag.

Jan Kiszka jan.kiszka at siemens.com
Wed Sep 2 11:16:36 CEST 2020

On 02.09.20 11:12, 孙世龙 sunshilong wrote:
> Hi,
>> That is a (reasonable) design decision because you would otherwise risk
>> that a handler registered for low-prio task can block the delivery of an
>> event for a high-prio task. I would just be a mess, at least in a more
>> complex RT application.
> I see, thank you for the clarification.
> It causes what can be done in the callback function of the alarm is very
> limited since a lot of APIs can not be invoked(i.e.:
> No data synchronization could be done by locking/unlocking RT_Mutex.
> Message pipe services(RT_QUEUE), Semaphore services(RT_SEM) and etc
> could not be called, too.)
> Am I right?

Conceptually, anything that blocks, yes. It's like an asynchronous
signal handler where many libc functions aren't available as well - or
you run into deadlocks (the classic printf-from-signal-handler bug...).


Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

More information about the Xenomai mailing list