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.
_______________________________________________
Xenomai mailing list
[email protected]
https://xenomai.org/mailman/listinfo/xenomai
