"cheap", RT-safe way of detecting if a thread is Xenomai or Linux

Giulio Moro g.moro at qmul.ac.uk
Sun Jan 13 13:55:00 CET 2019

> What is the use case of this query?

I am trying to write some C++ classes to wrap `pthread_mutex_...` and `pthread_cond_...` in such a way that the caller does not need to be aware of Xenomai. It would be up to the wrapping class to check whether it is being called by a Xenomai thread and whether xenomai has been init'ed before running any of:


If it detects that Xenomai has not been init'ed, it should do it. If it detects that it is *not* being called by a Xenomai thread, it should turn the current thread into a Xenomai thread. If there was a low-cost option to detect if we are on a Xenomai thread, then it could be checked before any such calls. In particular mutex_lock(), mutex_unlock(), cond_signal() are likely to be called from a RT-priority thread to which I would not want to add overhead.

Now that I think of it, I guess an alternative would be: 
A- if one of the _init() functions returns EPERM, it means Xenomai is not init'ed and should be init'ed
B- if any of the other functions returns EPERM, then it is not called from a Xenomai thread and the current thread should be switched to Xenomai.

Now I tested A and B, and it seems to work, any known pitfalls?


From: Jan Kiszka <jan.kiszka at web.de>
Sent: 13 January 2019 03:30
To: Giulio Moro; Xenomai at xenomai.org
Subject: Re: "cheap", RT-safe way of detecting if a thread is Xenomai or Linux

On 13.01.19 10:33, Giulio Moro via Xenomai wrote:
> Hi all,
> is there a "cheap", RT-safe call that can be made in order to find out if the current thread is a Xenomai thread or a Linux thread? Also, to detect whether the Xenomai thread is in primary or secondary mode?
> It seems that cobalt_thread_mode() gives some (all?) of these details. Is it RT-safe? How much overhead does it incur? Is it the recommended way?

What is the use case of this query? Debugging purposes? We expose APIs for the
latter (e.g. cobalt_assert_nrt(), typically only called by internal wrappers)
but we are intentionally not proposing them for production purposes.


More information about the Xenomai mailing list