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

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

[Giulio Moro]

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?

Thanks,
Giulio

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

[Jan Kiszka]

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.

Jan

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

[Giulio Moro]

> 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:

__wrap_pthread_mutex_init()
__wrap_pthread_cond_init()
__wrap_pthread_mutex_lock()
__wrap_pthread_mutex_unlock()
__wrap_pthread_cond_wait()
__wrap_pthread_cond_signal()

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?

Thanks,
Giulio

________________________________________
From: Jan Kiszka <jan.kiszka@web.de>
Sent: 13 January 2019 03:30
To: Giulio Moro; Xenomai@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.

Jan

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

[Julien Blanc]

Le dimanche 13 janvier 2019 à 02:33 +0000, Giulio Moro via Xenomai a
écrit :
> 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?

quoting Philippe, who i asked a similar question some time ago :

« cobalt_thread_pid(pthread_t) from the internal support library would
do the job. A successful call would denote a cobalt thread, -ESRCH
would denote a regular (or invalid) pthread. »

This works perfectly.

Julien