[Xenomai] trying to shadow a pthread fails with -EINVAL error

[Xenomai] trying to shadow a pthread fails with -EINVAL error

[Andrea]

Hello,

I'm currently trying to integrate Xenomai 3.0.2 using Cobalt with alchemy
skin in a C++  project, under kernel 4.1.8  with i-pipe patch.

In my application I'm creating some threads using boost library, and I
would like to shadow one of them to a rt_task in order to use some xenomai
function in there.

If I call rt_task_shadow(NULL, NULL, 0,0) from the running thread, -EINVAL
is returned.

While the API docs says that this can be due to an invalid prio, tracking
down the source of the error, it appears that in my case it is generated in
the function syncobj_lock (copperplate/syncobj.c), where a call to
monitor_enter (which internally calls cobalt_monitor_enter) fails and
returns -1.

The same happens with threads created both using standard pthread_create or
via the boost library.

Trying to shadow the main thread (or creating rt_task from there) works
correctly. instead.

A reproducible example in my system:

#include "pthread.h"
#include "alchemy/task.h"
#include <iostream>
#include <unistd.h>

void* shadow(void*)
{
    std::cerr<<"Shadow returned "<< rt_task_shadow(NULL, NULL, 0,0);
}

int main(int argc, char* argv[])
{
    pthread_t test_thread;
   // new boost::thread(shadow);
    pthread_create(&test_thread, NULL, shadow, NULL);
    sleep(10);

    return 0;
}

with output: Shadow returned -22

Do you have any insight on where the problem could be? Am I missing
something basic?

If possible, I would like to stick to alchemy skin.

Thank you in advance for your help,

Andrea

Re: [Xenomai] trying to shadow a pthread fails with -EINVAL error

[Philippe Gerum]

On 04/19/2016 04:08 PM, Andrea wrote:
> Hello,
>
> I'm currently trying to integrate Xenomai 3.0.2 using Cobalt with alchemy
> skin in a C++  project, under kernel 4.1.8  with i-pipe patch.
>
> In my application I'm creating some threads using boost library, and I
> would like to shadow one of them to a rt_task in order to use some xenomai
> function in there.
>
> If I call rt_task_shadow(NULL, NULL, 0,0) from the running thread, -EINVAL
> is returned.
>
> While the API docs says that this can be due to an invalid prio, tracking
> down the source of the error, it appears that in my case it is generated in
> the function syncobj_lock (copperplate/syncobj.c), where a call to
> monitor_enter (which internally calls cobalt_monitor_enter) fails and
> returns -1.
>
> The same happens with threads created both using standard pthread_create or
> via the boost library.
>
> Trying to shadow the main thread (or creating rt_task from there) works
> correctly. instead.
>
> A reproducible example in my system:
>
> #include "pthread.h"
> #include "alchemy/task.h"
> #include <iostream>
> #include <unistd.h>
>
> void* shadow(void*)
> {
>      std::cerr<<"Shadow returned "<< rt_task_shadow(NULL, NULL, 0,0);
> }
>
> int main(int argc, char* argv[])
> {
>      pthread_t test_thread;
>     // new boost::thread(shadow);
>      pthread_create(&test_thread, NULL, shadow, NULL);
>      sleep(10);
>
>      return 0;
> }
>
> with output: Shadow returned -22
>
> Do you have any insight on where the problem could be? Am I missing
> something basic?
>

I suspect some chicken and egg situation in the rt_task_shadow() 
implementation. I'll have a look as soon as I can.

> If possible, I would like to stick to alchemy skin.

Unfortunately, the only way to work around this issue at the moment 
would be to call libcobalt's pthread_setschedparam() for pthread_self(), 
until this issue is fixed in libalchemy. You could do this for a 
particular statement without wrapping the POSIX API by calling:

struct sched_param parm = { .sched_priority = 0 };
__RT(pthread_setschedparam(phread_self(), SCHED_OTHER, &parm);

instead of rt_task_shadow(). libcobalt is underlying all Xenomai 3 
applications, so you would not need to fixup the build rules or 
dependencies. It's already there.

-- 
Philippe.

Re: [Xenomai] trying to shadow a pthread fails with -EINVAL error

[Andrea]

Hello Philippe,

Thank you very much for your prompt answer,
I tried the proposed workaround and it seems to work fine on threads
created with both pthread_create and boost library, effectively solving my
problem.

After shadowing the thread in the suggested way, it seems that I can use
libalchemy as intended and even spawn new rt_tasks from the shadowed thread.

I'll keep using libalchemy, with the workaround where needed, as you
suggested.

Thank you again for your very useful help,

Andrea





2016-04-19 16:31 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:

> On 04/19/2016 04:08 PM, Andrea wrote:
>
>> Hello,
>>
>> I'm currently trying to integrate Xenomai 3.0.2 using Cobalt with alchemy
>> skin in a C++  project, under kernel 4.1.8  with i-pipe patch.
>>
>> In my application I'm creating some threads using boost library, and I
>> would like to shadow one of them to a rt_task in order to use some xenomai
>> function in there.
>>
>> If I call rt_task_shadow(NULL, NULL, 0,0) from the running thread, -EINVAL
>> is returned.
>>
>> While the API docs says that this can be due to an invalid prio, tracking
>> down the source of the error, it appears that in my case it is generated
>> in
>> the function syncobj_lock (copperplate/syncobj.c), where a call to
>> monitor_enter (which internally calls cobalt_monitor_enter) fails and
>> returns -1.
>>
>> The same happens with threads created both using standard pthread_create
>> or
>> via the boost library.
>>
>> Trying to shadow the main thread (or creating rt_task from there) works
>> correctly. instead.
>>
>> A reproducible example in my system:
>>
>> #include "pthread.h"
>> #include "alchemy/task.h"
>> #include <iostream>
>> #include <unistd.h>
>>
>> void* shadow(void*)
>> {
>>      std::cerr<<"Shadow returned "<< rt_task_shadow(NULL, NULL, 0,0);
>> }
>>
>> int main(int argc, char* argv[])
>> {
>>      pthread_t test_thread;
>>     // new boost::thread(shadow);
>>      pthread_create(&test_thread, NULL, shadow, NULL);
>>      sleep(10);
>>
>>      return 0;
>> }
>>
>> with output: Shadow returned -22
>>
>> Do you have any insight on where the problem could be? Am I missing
>> something basic?
>>
>>
> I suspect some chicken and egg situation in the rt_task_shadow()
> implementation. I'll have a look as soon as I can.
>
> If possible, I would like to stick to alchemy skin.
>>
>
> Unfortunately, the only way to work around this issue at the moment would
> be to call libcobalt's pthread_setschedparam() for pthread_self(), until
> this issue is fixed in libalchemy. You could do this for a particular
> statement without wrapping the POSIX API by calling:
>
> struct sched_param parm = { .sched_priority = 0 };
> __RT(pthread_setschedparam(phread_self(), SCHED_OTHER, &parm);
>
> instead of rt_task_shadow(). libcobalt is underlying all Xenomai 3
> applications, so you would not need to fixup the build rules or
> dependencies. It's already there.
>
> --
> Philippe.
>

Re: [Xenomai] trying to shadow a pthread fails with -EINVAL error

[Philippe Gerum]

On 04/19/2016 04:31 PM, Philippe Gerum wrote:
> On 04/19/2016 04:08 PM, Andrea wrote:
>> Hello,
>>
>> I'm currently trying to integrate Xenomai 3.0.2 using Cobalt with alchemy
>> skin in a C++  project, under kernel 4.1.8  with i-pipe patch.
>>
>> In my application I'm creating some threads using boost library, and I
>> would like to shadow one of them to a rt_task in order to use some
>> xenomai
>> function in there.
>>
>> If I call rt_task_shadow(NULL, NULL, 0,0) from the running thread,
>> -EINVAL
>> is returned.
>>
>> While the API docs says that this can be due to an invalid prio, tracking
>> down the source of the error, it appears that in my case it is
>> generated in
>> the function syncobj_lock (copperplate/syncobj.c), where a call to
>> monitor_enter (which internally calls cobalt_monitor_enter) fails and
>> returns -1.
>>
>> The same happens with threads created both using standard
>> pthread_create or
>> via the boost library.
>>
>> Trying to shadow the main thread (or creating rt_task from there) works
>> correctly. instead.
>>
>> A reproducible example in my system:
>>
>> #include "pthread.h"
>> #include "alchemy/task.h"
>> #include <iostream>
>> #include <unistd.h>
>>
>> void* shadow(void*)
>> {
>>      std::cerr<<"Shadow returned "<< rt_task_shadow(NULL, NULL, 0,0);
>> }
>>
>> int main(int argc, char* argv[])
>> {
>>      pthread_t test_thread;
>>     // new boost::thread(shadow);
>>      pthread_create(&test_thread, NULL, shadow, NULL);
>>      sleep(10);
>>
>>      return 0;
>> }
>>
>> with output: Shadow returned -22
>>
>> Do you have any insight on where the problem could be? Am I missing
>> something basic?
>>
>
> I suspect some chicken and egg situation in the rt_task_shadow()
> implementation. I'll have a look as soon as I can.
>
>> If possible, I would like to stick to alchemy skin.
>
> Unfortunately, the only way to work around this issue at the moment
> would be to call libcobalt's pthread_setschedparam() for pthread_self(),
> until this issue is fixed in libalchemy. You could do this for a
> particular statement without wrapping the POSIX API by calling:
>
> struct sched_param parm = { .sched_priority = 0 };
> __RT(pthread_setschedparam(phread_self(), SCHED_OTHER, &parm);
>
> instead of rt_task_shadow(). libcobalt is underlying all Xenomai 3
> applications, so you would not need to fixup the build rules or
> dependencies. It's already there.
>

Ok, so my suspicion turned out to be true, rt_task_shadow() used to call 
Cobalt services for creating ... a Cobalt context, which is not exactly 
a bright idea. This is fixed in the stable- and next- branches.

However, rt_task_create() is still not usable from a plain regular POSIX 
thread; this could be done, but at the expense of significant changes 
that do not seem worth it, given that calling __STD(pthread_create()) 
followed by running rt_task_shadow() from the created regular pthread 
would lead to the same result than creating a real-time thread directly 
from a regular pthread context.

The rationale is that a main thread is automatically turned into a 
Cobalt thread during early init, prior to entering the main() routine 
(unless automatic Xenomai bootstrap was disabled though). Therefore an 
application may fully instantiate the system, calling any Xenomai 
service over the main() context to do so.

rt_task_shadow() (as fixed) should be used to turn a plain pthread 
context into a Xenomai thread, before the latter invokes other calls 
from the Alchemy API.

-- 
Philippe.