> 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 <[email protected]> Sent: 13 January 2019 03:30 To: Giulio Moro; [email protected] 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
