rt_task_unblock() POSIX alternative

rt_task_unblock() POSIX alternative

[Petr Červenka]

Hello everyone.
I there a rt_task_unblock() Xenomai POSIX skin alternative?
I created an example of periodic POSIX task, similar to the latency example but with very long period. When I receive a INT signal I set the end flag and I would like to unblock a task that waits on read(timerfd). But all my attempts led to standard wait timeout or worse.
Thanks in advance.
Best regards
Petr Cervenka

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 07.04.20 15:41, Petr Červenka via Xenomai wrote:
> Hello everyone.
> I there a rt_task_unblock() Xenomai POSIX skin alternative?
> I created an example of periodic POSIX task, similar to the latency example but with very long period. When I receive a INT signal I set the end flag and I would like to unblock a task that waits on read(timerfd). But all my attempts led to standard wait timeout or worse.

Try pthread_cancel(). If you need to run some cleanup code in the target 
thread, use pthread_cleanup_push. None of that would be with real-time 
qualities, though. But I assume that the cleanup is not a time-critical 
path, is it?

Sending a Linux signal would be another way to interrupt the target task.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

Hello Jan.
And if I don't want to totally remove the thread? Only to interrupt the waiting and react according to new events (like reconfiguring something or starting to wait on different resource).
Is there some pthread_create... or sched_... parameter or flag, that the task's system call can be interruptible?
And how to use the signals to interrupt it? Call of kill(task_pid, SIGINT) didn't helped.
Petr
 
______________________________________________________________
> From "Jan Kiszka" <jan.kiszka@siemens.com>
>
On 07.04.20 15:41, Petr Červenka via Xenomai wrote:
 > Hello everyone.
 > I there a rt_task_unblock() Xenomai POSIX skin alternative?
 > I created an example of periodic POSIX task, similar to the latency example but with very long period. When I receive a INT signal I set the end flag and I would like to unblock a task that waits on read(timerfd). But all my attempts led to standard wait timeout or worse.
 
 Try pthread_cancel(). If you need to run some cleanup code in the target 
 thread, use pthread_cleanup_push. None of that would be with real-time 
 qualities, though. But I assume that the cleanup is not a time-critical 
 path, is it?
 
 Sending a Linux signal would be another way to interrupt the target task.
 
 Jan
 
 -- 
 Siemens AG, Corporate Technology, CT RDA IOT SES-DE
 Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 07.04.20 17:18, Petr Červenka wrote:
> Hello Jan.
> And if I don't want to totally remove the thread? Only to interrupt the waiting and react according to new events (like reconfiguring something or starting to wait on different resource).
> Is there some pthread_create... or sched_... parameter or flag, that the task's system call can be interruptible?
> And how to use the signals to interrupt it? Call of kill(task_pid, SIGINT) didn't helped.

Use __STD(pthread_kill) to target a specific thread.

But if you want to continue the thread after interruption, you may be 
looking for a RT channel. In that case, poll on the timerfd and a 
messaging channel like an mqueue or an iddp socket is more appropriate.

Jan

> Petr
>   
> ______________________________________________________________
>>  From "Jan Kiszka" <jan.kiszka@siemens.com>
>>
> On 07.04.20 15:41, Petr Červenka via Xenomai wrote:
>   > Hello everyone.
>   > I there a rt_task_unblock() Xenomai POSIX skin alternative?
>   > I created an example of periodic POSIX task, similar to the latency example but with very long period. When I receive a INT signal I set the end flag and I would like to unblock a task that waits on read(timerfd). But all my attempts led to standard wait timeout or worse.
>   
>   Try pthread_cancel(). If you need to run some cleanup code in the target
>   thread, use pthread_cleanup_push. None of that would be with real-time
>   qualities, though. But I assume that the cleanup is not a time-critical
>   path, is it?
>   
>   Sending a Linux signal would be another way to interrupt the target task.
>   
>   Jan
>   
>   --
>   Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>   Corporate Competence Center Embedded Linux
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 7, 2020 at 5:18 PM Petr Červenka via Xenomai
<xenomai@xenomai.org> wrote:
>
> Hello Jan.
> And if I don't want to totally remove the thread? Only to interrupt the waiting and react according to new events (like reconfiguring something or starting to wait on different resource).
> Is there some pthread_create... or sched_... parameter or flag, that the task's system call can be interruptible?
> And how to use the signals to interrupt it? Call of kill(task_pid, SIGINT) didn't helped.

Use pthread_kill() plus a custom signal. Such as SIGRTMIN + 2.

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

> Use pthread_kill() plus a custom signal. Such as SIGRTMIN + 2.
Calling of kill() or pthread_kill() does not help. Nothing is able to interrupt read() from timerfd (only pthread_cancel). Do I have to prepare the task or timerfd to be interruptible by a signal?
Petr

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Wed, Apr 8, 2020 at 11:44 AM Petr Červenka <grugh@centrum.cz> wrote:
>
> > Use pthread_kill() plus a custom signal. Such as SIGRTMIN + 2.
> Calling of kill() or pthread_kill() does not help. Nothing is able to interrupt read() from timerfd (only pthread_cancel). Do I have to prepare the task or timerfd to be interruptible by a signal?

Using the signal you can interrupt the system call. Of course only if
the system call is currently interruptable.
pthread_cancel() in async mode also just sends a signal (SIGCANCEL)
and terminates the thread in a more or less sane way.

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Wed, Apr 8, 2020 at 11:44 AM Petr Červenka <grugh@centrum.cz> wrote:
>
> > Use pthread_kill() plus a custom signal. Such as SIGRTMIN + 2.
> Calling of kill() or pthread_kill() does not help. Nothing is able to interrupt read() from timerfd (only pthread_cancel). Do I have to prepare the task or timerfd to be interruptible by a signal?

BTW: Why do you think nothing can interrupt a read() from a timerfd?
If read() blocks on a timerfd the calling thread will be put into
interruptable sleep.

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

> BTW:
> Why do you think nothing can interrupt a read() from a timerfd?
> If read() blocks on a timerfd the calling thread will be put into
> interruptable sleep.
 
"I" was not able to send a signal to the task and interrupt it.
Here is an example. Please let me know, how to improve it to interrupt the read() before its timeout:
 
#include <math.h>
#include <pthread.h>
#include <stdint.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/timerfd.h>
#include <unistd.h>

#define AUTO_KILL

#define SECOND  1000000000l     // ns
#define PERIOD  (5 * SECOND)    // ns
#define SLEEP   (1 * SECOND)    // ns

using namespace std;

static pid_t mainTask_pid;
static pthread_t task;
static int timer_fd;
static bool end = false;

void signalHandler(int signal) {
    int err;
    printf("Signal handler: %d\n", signal);
    end = true;
    err = pthread_kill(task, SIGINT);
    if (err != 0) {
        printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
    }
    printf("Signal handler end\n");
}

void timediff (struct timespec *result, const struct timespec *t1, const struct timespec *t2) {
    result->tv_sec = t2->tv_sec - t1->tv_sec;
    result->tv_nsec = t2->tv_nsec - t1->tv_nsec;
    if (result->tv_nsec >= SECOND) {
        result->tv_nsec -= SECOND;
        result->tv_sec++;
    }
    if (result->tv_nsec < 0) {
        result->tv_nsec += SECOND;
        result->tv_sec--;
    }
}

static void *taskHandler(void *cookie) {
    int err;

    printf("Task started\n");

    signal(SIGINT, signalHandler);
    signal(SIGTERM, signalHandler);

    // Get current time
    struct timespec start;
    clock_gettime(CLOCK_MONOTONIC, &start);

    // Set task period
    timer_fd = timerfd_create(CLOCK_MONOTONIC, 0);
    struct itimerspec timer_conf;
    timer_conf.it_value.tv_sec      = start.tv_sec;
    timer_conf.it_value.tv_nsec     = start.tv_nsec;
    timer_conf.it_interval.tv_sec   = PERIOD / SECOND;
    timer_conf.it_interval.tv_nsec  = PERIOD % SECOND;
    printf("Set period: %.3gs\n", timer_conf.it_interval.tv_sec + (double) timer_conf.it_interval.tv_nsec / SECOND);
    err = timerfd_settime(timer_fd, TFD_TIMER_ABSTIME, &timer_conf, NULL);
    if (err != 0) {
        printf("timerfd_settime failed: %d (%s)\n", err, strerror(-err));
        return NULL;
    }

    // Main cycle
    while (!end) {
        // Wait next period
        uint64_t ticks;
        ::read(timer_fd, &ticks, sizeof (ticks));

        // Get current time
        struct timespec now, result;
        clock_gettime(CLOCK_MONOTONIC, &now);

        // Printf wait time
        timediff(&result, &start, &now);
        printf("Task livind: %.3gs\n", result.tv_sec + (double) result.tv_nsec / SECOND);
        start = now;
    }

    ::close(timer_fd);
    printf("Task ended\n");
}

/*
 * 
 */
int main(int argc, char** argv) {
    unsigned long overruns;
    int err;

    mlockall(MCL_CURRENT | MCL_FUTURE);

    // Setup signal handler
    signal(SIGINT, signalHandler);
    signal(SIGTERM, signalHandler);

    // Get current process ID
    mainTask_pid = getpid();

    // Make main task real-time (prio 1)
    sched_param param;
    memset(&param, 0, sizeof(param));
    param.sched_priority = 1;
    err = sched_setscheduler(mainTask_pid, SCHED_FIFO, &param);
    if (err != 0) {
        printf("sched_setscheduler failed: %d (%s)\n", err, strerror(-err));
        goto sched_setscheduler_err;
    }

    // Create new task (prio 2)
    pthread_attr_t tattr;
    pthread_attr_init(&tattr);
    pthread_attr_setinheritsched(&tattr, PTHREAD_EXPLICIT_SCHED);
    pthread_attr_setschedpolicy(&tattr, SCHED_FIFO);
    memset(&param, 0, sizeof (param));
    param.sched_priority = 2;
    pthread_attr_setschedparam(&tattr, &param);
    err = pthread_create(&task, &tattr, taskHandler, NULL);
    if (err != 0) {
        printf("pthread_create failed: %d (%s)\n", err, strerror(-err));
        goto pthread_create_err;
    }

#ifndef AUTO_KILL
    printf("Press ^C to stop!\n");
    do {
        pause();
    } while(!end);
#else
    usleep(SLEEP / 1000);

    // Call of signal handler
    err = kill(0, SIGINT);  // THE ONLY ONE WHICH WORKS !!!
    //err = kill(getpid(), SIGINT);
    //err = kill(mainTask_pid, SIGINT);
    //err = pthread_kill(pthread_self(), SIGINT);
    //err = pthread_kill(task, SIGINT);
    if (err != 0) {
        printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
    }
#endif

    printf("Waiting for join\n");
    //pthread_cancel(task);
    pthread_join(task, NULL);
pthread_create_err:
sched_setaffinity_err:
sched_setscheduler_err:
    return 0;
}

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Thu, Apr 9, 2020 at 5:00 PM Petr Červenka <grugh@centrum.cz> wrote:
>
> > BTW:
> > Why do you think nothing can interrupt a read() from a timerfd?
> > If read() blocks on a timerfd the calling thread will be put into
> > interruptable sleep.
>
> "I" was not able to send a signal to the task and interrupt it.
> Here is an example. Please let me know, how to improve it to interrupt the read() before its timeout:
>
> #include <math.h>
> #include <pthread.h>
> #include <stdint.h>
> #include <signal.h>
> #include <stdio.h>
> #include <string.h>
> #include <sys/mman.h>
> #include <sys/timerfd.h>
> #include <unistd.h>
>
> #define AUTO_KILL
>
> #define SECOND  1000000000l     // ns
> #define PERIOD  (5 * SECOND)    // ns
> #define SLEEP   (1 * SECOND)    // ns
>
> using namespace std;
>
> static pid_t mainTask_pid;
> static pthread_t task;
> static int timer_fd;
> static bool end = false;
>
> void signalHandler(int signal) {
>     int err;
>     printf("Signal handler: %d\n", signal);
>     end = true;
>     err = pthread_kill(task, SIGINT);
>     if (err != 0) {
>         printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
>     }
>     printf("Signal handler end\n");
> }
>
> void timediff (struct timespec *result, const struct timespec *t1, const struct timespec *t2) {
>     result->tv_sec = t2->tv_sec - t1->tv_sec;
>     result->tv_nsec = t2->tv_nsec - t1->tv_nsec;
>     if (result->tv_nsec >= SECOND) {
>         result->tv_nsec -= SECOND;
>         result->tv_sec++;
>     }
>     if (result->tv_nsec < 0) {
>         result->tv_nsec += SECOND;
>         result->tv_sec--;
>     }
> }
>
> static void *taskHandler(void *cookie) {
>     int err;
>
>     printf("Task started\n");
>
>     signal(SIGINT, signalHandler);
>     signal(SIGTERM, signalHandler);

Don't use signal().
Use sigaction() and *don't* set SA_RESTART. Maybe read() is always restarted...

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

> Don't use signal().
> Use sigaction() and *don't* set SA_RESTART. Maybe read() is always restarted...
 
Thank you for trying to help me.
But with the sigaction (without SA_RESTART) the behavior is completely the same:
Only Ctrl+C or kill(0, SIGINT) are able to invoke the signalHandler.The read() is not interrupted (maybe syscall restart in some inner cycle).Example of the signal handler setup:
    // Setup signal handler
    struct sigaction act;
    memset(&act, 0, sizeof (act));
    act.sa_handler = signalHandler;
    sigaction(SIGINT, &act, NULL);
    sigaction(SIGTERM, &act, NULL);
 
Petr

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Thu, Apr 9, 2020 at 8:10 PM Petr Červenka <grugh@centrum.cz> wrote:
>
> > Don't use signal().
> > Use sigaction() and *don't* set SA_RESTART. Maybe read() is always restarted...
>
>
>
> Thank you for trying to help me.
>
> But with the sigaction (without SA_RESTART) the behavior is completely the same:
>
> Only Ctrl+C or kill(0, SIGINT) are able to invoke the signalHandler.
> The read() is not interrupted (maybe syscall restart in some inner cycle).
>
> Example of the signal handler setup:
>
>     // Setup signal handler
>     struct sigaction act;
>     memset(&act, 0, sizeof (act));
>     act.sa_handler = signalHandler;
>     sigaction(SIGINT, &act, NULL);
>     sigaction(SIGTERM, &act, NULL);

I gave your program a try.
With this changes it works (at least how I understand your test case).

Task started
Set period: 5s
Task livind: 9.9e-05s
Waiting for join
Signal handler: 41
Signal handler end
Task livind: 0.999s
Task ended

diff --git a/read_intr.cpp b/read_intr.cpp
index 722f69c..1c5ef53 100644
--- a/read_intr.cpp
+++ b/read_intr.cpp
@@ -21,14 +21,10 @@ static pthread_t task;
 static int timer_fd;
 static bool end = false;

-void signalHandler(int signal) {
+void signalHandler(int signal, siginfo_t *info, void *ctx) {
     int err;
     printf("Signal handler: %d\n", signal);
     end = true;
-    err = pthread_kill(task, SIGINT);
-    if (err != 0) {
-        printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
-    }
     printf("Signal handler end\n");
 }

@@ -50,9 +46,6 @@ static void *taskHandler(void *cookie) {

     printf("Task started\n");

-    signal(SIGINT, signalHandler);
-    signal(SIGTERM, signalHandler);
-
     // Get current time
     struct timespec start;
     clock_gettime(CLOCK_MONOTONIC, &start);
@@ -97,13 +90,15 @@ static void *taskHandler(void *cookie) {
 int main(int argc, char** argv) {
     unsigned long overruns;
     int err;
+    struct sigaction sa = {0};

     mlockall(MCL_CURRENT | MCL_FUTURE);

     // Setup signal handler
-    signal(SIGINT, signalHandler);
-    signal(SIGTERM, signalHandler);
-
+    sa.sa_flags = 0;
+    sigemptyset(&sa.sa_mask);
+    sa.sa_sigaction = signalHandler;
+    sigaction(SIGRTMIN + 7, &sa, NULL);
     // Get current process ID
     mainTask_pid = getpid();

@@ -140,11 +135,11 @@ int main(int argc, char** argv) {
     usleep(SLEEP / 1000);

     // Call of signal handler
-    err = kill(0, SIGINT);  // THE ONLY ONE WHICH WORKS !!!
+    //err = kill(0, SIGINT);  // THE ONLY ONE WHICH WORKS !!!
     //err = kill(getpid(), SIGINT);
     //err = kill(mainTask_pid, SIGINT);
     //err = pthread_kill(pthread_self(), SIGINT);
-    //err = pthread_kill(task, SIGINT);
+    err = pthread_kill(task, SIGRTMIN + 7);
     if (err != 0) {
         printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
     }


-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

Hello Richard.
Sorry for late answer because of the Easter.

 > I gave your program a try.
> With this changes it works (at least how I understand your test case).
 > 
> Task started
> Set period: 5s
> Task livind: 9.9e-05s
> Waiting for join
> Signal handler: 41
> Signal handler end
> Task livind: 0.999s
> Task ended
 >
> ...
 
There has to be something with my version of Xenomai, IPIPE or configuration. Not even your example is working for me. Morover in your example output is clearly visible, that the first waiting is interrupted 9.9e-05s after first attempt to wait by some unknown signal. Such thing has never happened to me in POSIX, only in Alchemy.
 
My output:
Task started
Set period: 5s
Waiting for join
Task livind: 5s
Task livind: 5s
Task livind: 5s
...
 
Also here is perhaps a small fix to your changes: sa.sa_flags = SA_SIGINFO;
 
user@user-desktop:~$ uname -a
Linux user-desktop 4.19.109-xenomai #1 SMP Fri Apr 3 13:51:40 CEST 2020 x86_64 x86_64 x86_64 GNU/Linux
 
user@user-desktop:~$ /usr/xenomai/bin/xeno-config --verbose
xeno-config --verbose
        --core=cobalt
        --version="3.1"
        --cc="gcc"
        --ccld="/usr/xenomai/bin/wrap-link.sh gcc"
        --arch="x86"
        --prefix="/usr/xenomai"
        --library-dir="/usr/xenomai/lib"
 
IPIPE patch: ipipe-core-4.19.109-cip22-x86-11.patch
 
Petr

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 10:16 AM Petr Červenka <grugh@centrum.cz> wrote:
>
> Hello Richard.
> Sorry for late answer because of the Easter.
>
>  > I gave your program a try.
> > With this changes it works (at least how I understand your test case).
>  >
> > Task started
> > Set period: 5s
> > Task livind: 9.9e-05s
> > Waiting for join
> > Signal handler: 41
> > Signal handler end
> > Task livind: 0.999s
> > Task ended
>  >
> > ...
>
> There has to be something with my version of Xenomai, IPIPE or configuration. Not even your example is working for me. Morover in your example output is clearly visible, that the first waiting is interrupted 9.9e-05s after first attempt to wait by some unknown signal. Such thing has never happened to me in POSIX, only in Alchemy.

I fear there seems to be a confusion between POSIX tasks and POSIX skin.
Is your goal programming Xenomai realtime threads using POSIX alike APIs?
Or are you looking for a pedant of rt_task_unblock() to unblock a
POSIX task, without Xenomai realtime threads?

The solution I provided is for the latter case.

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

> I fear there seems to be a confusion between POSIX tasks and POSIX skin.
> Is your goal programming Xenomai realtime threads using POSIX alike APIs?
> Or are you looking for a pedant of rt_task_unblock() to unblock a
> POSIX task, without Xenomai realtime threads?
 > 
> The solution I provided is for the latter case.
 
My original goal was to port a very complex realtime application from Xenomai 2.6.5 Native skin to Xenomai 3.1 POSIX skin. So I made series of examples, where I tried to verify porting of several designs used in the orig. application. And rt_task_unblock() for reconfiguration of the waiting threads in the orig app was one of them.
Now I'm very curious, why the (my explicit) signals in Xenomai POSIX skin are not working for me as I would expect.
 
Here is my compile command:
g++ -fasynchronous-unwind-tables   -c -g -D_DEBUG -D_GNU_SOURCE -D_REENTRANT -D__COBALT_WRAP__ -D__COBALT__ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
 
Here is my link command:
g++ -fasynchronous-unwind-tables    -o dist/Debug/GNU-Linux/countertestapp_4 build/Debug/GNU-Linux/main.o -L/usr/xenomai/lib -Wl,-rpath,'/usr/xenomai/lib' -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -lcobalt -lmodechk -lpthread -lrt
 
I'm using Netbeans IDE for my attemps, but the I tried to integrate xeno-config --posix --cflags or --ldflags result into the project settings as much as possible.
Petr

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 11:11 AM Petr Červenka <grugh@centrum.cz> wrote:
>
> > I fear there seems to be a confusion between POSIX tasks and POSIX skin.
> > Is your goal programming Xenomai realtime threads using POSIX alike APIs?
> > Or are you looking for a pedant of rt_task_unblock() to unblock a
> > POSIX task, without Xenomai realtime threads?
> >
> > The solution I provided is for the latter case.
>
>
>
> My original goal was to port a very complex realtime application from Xenomai 2.6.5 Native skin to Xenomai 3.1 POSIX skin. So I made series of examples, where I tried to verify porting of several designs used in the orig. application. And rt_task_unblock() for reconfiguration of the waiting threads in the orig app was one of them.
>
> Now I'm very curious, why the (my explicit) signals in Xenomai POSIX skin are not working for me as I would expect.
>
>
>
> Here is my compile command:
>
> g++ -fasynchronous-unwind-tables   -c -g -D_DEBUG -D_GNU_SOURCE -D_REENTRANT -D__COBALT_WRAP__ -D__COBALT__ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
>
>
>
> Here is my link command:
>
> g++ -fasynchronous-unwind-tables    -o dist/Debug/GNU-Linux/countertestapp_4 build/Debug/GNU-Linux/main.o -L/usr/xenomai/lib -Wl,-rpath,'/usr/xenomai/lib' -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -lcobalt -lmodechk -lpthread -lrt
>
>
>
> I'm using Netbeans IDE for my attemps, but the I tried to integrate xeno-config --posix --cflags or --ldflags result into the project settings as much as possible.

Okay. Now things get clearer.
pthread_kill() will be wrapped to Xenomai, but you installed a signal
handler for a Linux process.

What you basically need is a function in the Xenomai POSIX skin which
calls threadobj_unblock().

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 14.04.20 11:46, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 11:11 AM Petr Červenka <grugh@centrum.cz> wrote:
>>
>>> I fear there seems to be a confusion between POSIX tasks and POSIX skin.
>>> Is your goal programming Xenomai realtime threads using POSIX alike APIs?
>>> Or are you looking for a pedant of rt_task_unblock() to unblock a
>>> POSIX task, without Xenomai realtime threads?
>>>
>>> The solution I provided is for the latter case.
>>
>>
>>
>> My original goal was to port a very complex realtime application from Xenomai 2.6.5 Native skin to Xenomai 3.1 POSIX skin. So I made series of examples, where I tried to verify porting of several designs used in the orig. application. And rt_task_unblock() for reconfiguration of the waiting threads in the orig app was one of them.
>>
>> Now I'm very curious, why the (my explicit) signals in Xenomai POSIX skin are not working for me as I would expect.
>>
>>
>>
>> Here is my compile command:
>>
>> g++ -fasynchronous-unwind-tables   -c -g -D_DEBUG -D_GNU_SOURCE -D_REENTRANT -D__COBALT_WRAP__ -D__COBALT__ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
>>
>>
>>
>> Here is my link command:
>>
>> g++ -fasynchronous-unwind-tables    -o dist/Debug/GNU-Linux/countertestapp_4 build/Debug/GNU-Linux/main.o -L/usr/xenomai/lib -Wl,-rpath,'/usr/xenomai/lib' -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -lcobalt -lmodechk -lpthread -lrt
>>
>>
>>
>> I'm using Netbeans IDE for my attemps, but the I tried to integrate xeno-config --posix --cflags or --ldflags result into the project settings as much as possible.
> 
> Okay. Now things get clearer.
> pthread_kill() will be wrapped to Xenomai, but you installed a signal
> handler for a Linux process.
> 
> What you basically need is a function in the Xenomai POSIX skin which
> calls threadobj_unblock().
> 

Below the working version for unblocking the RT task with non-RT signal.

Jan

---


#include <math.h>
#include <pthread.h>
#include <stdint.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/timerfd.h>
#include <unistd.h>

#define AUTO_KILL

#define SECOND  1000000000l     // ns
#define PERIOD  (5 * SECOND)    // ns
#define SLEEP   (1 * SECOND)    // ns

using namespace std;

static pid_t mainTask_pid;
static pthread_t task;
static int timer_fd;
static volatile bool end = false;

void signalHandler(int signal, siginfo_t *info, void *ctx) {
    end = true;
}

void timediff (struct timespec *result, const struct timespec *t1, const struct timespec *t2) {
    result->tv_sec = t2->tv_sec - t1->tv_sec;
    result->tv_nsec = t2->tv_nsec - t1->tv_nsec;
    if (result->tv_nsec >= SECOND) {
        result->tv_nsec -= SECOND;
        result->tv_sec++;
    }
    if (result->tv_nsec < 0) {
        result->tv_nsec += SECOND;
        result->tv_sec--;
    }
}

static void *taskHandler(void *cookie) {
    struct sigaction sa = {0};
    int err;

    printf("Task started\n");

    sa.sa_flags = 0;
    sigemptyset(&sa.sa_mask);
    sa.sa_sigaction = signalHandler;
    sigaction(SIGUSR1, &sa, NULL);

    // Get current time
    struct timespec start;
    clock_gettime(CLOCK_MONOTONIC, &start);

    // Set task period
    timer_fd = timerfd_create(CLOCK_MONOTONIC, 0);
    struct itimerspec timer_conf;
    timer_conf.it_value.tv_sec      = start.tv_sec;
    timer_conf.it_value.tv_nsec     = start.tv_nsec;
    timer_conf.it_interval.tv_sec   = PERIOD / SECOND;
    timer_conf.it_interval.tv_nsec  = PERIOD % SECOND;
    printf("Set period: %.3gs\n", timer_conf.it_interval.tv_sec + (double) timer_conf.it_interval.tv_nsec / SECOND);
    err = timerfd_settime(timer_fd, TFD_TIMER_ABSTIME, &timer_conf, NULL);
    if (err != 0) {
        printf("timerfd_settime failed: %d (%s)\n", err, strerror(-err));
        return NULL;
    }

    // Main cycle
    while (!end) {
        // Wait next period
        uint64_t ticks;
        ::read(timer_fd, &ticks, sizeof (ticks));

        // Get current time
        struct timespec now, result;
        clock_gettime(CLOCK_MONOTONIC, &now);

        // Printf wait time
        timediff(&result, &start, &now);
        printf("Task livind: %.3gs\n", result.tv_sec + (double) result.tv_nsec / SECOND);
        start = now;
    }

    ::close(timer_fd);
    printf("Task ended\n");
}

/*
 * 
 */
int main(int argc, char** argv) {
    unsigned long overruns;
    int err;

    mlockall(MCL_CURRENT | MCL_FUTURE);

    // Get current process ID
    mainTask_pid = getpid();

    // Make main task real-time (prio 1)
    sched_param param;
    memset(&param, 0, sizeof(param));
    param.sched_priority = 1;
    err = sched_setscheduler(mainTask_pid, SCHED_FIFO, &param);
    if (err != 0) {
        printf("sched_setscheduler failed: %d (%s)\n", err, strerror(-err));
        goto sched_setscheduler_err;
    }

    // Create new task (prio 2)
    pthread_attr_t tattr;
    pthread_attr_init(&tattr);
    pthread_attr_setinheritsched(&tattr, PTHREAD_EXPLICIT_SCHED);
    pthread_attr_setschedpolicy(&tattr, SCHED_FIFO);
    memset(&param, 0, sizeof (param));
    param.sched_priority = 2;
    pthread_attr_setschedparam(&tattr, &param);
    err = pthread_create(&task, &tattr, taskHandler, NULL);
    if (err != 0) {
        printf("pthread_create failed: %d (%s)\n", err, strerror(-err));
        goto pthread_create_err;
    }

#ifndef AUTO_KILL
    printf("Press ^C to stop!\n");
    do {
        pause();
    } while(!end);
#else
    usleep(SLEEP / 1000);

    err = __STD(pthread_kill)(task, SIGUSR1);
    if (err != 0) {
        printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
    }
#endif

    printf("Waiting for join\n");
    //pthread_cancel(task);
    pthread_join(task, NULL);
pthread_create_err:
sched_setaffinity_err:
sched_setscheduler_err:
    return 0;
}

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 12:07 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 14.04.20 11:46, Richard Weinberger wrote:
> > On Tue, Apr 14, 2020 at 11:11 AM Petr Červenka <grugh@centrum.cz> wrote:
> >>
> >>> I fear there seems to be a confusion between POSIX tasks and POSIX skin.
> >>> Is your goal programming Xenomai realtime threads using POSIX alike APIs?
> >>> Or are you looking for a pedant of rt_task_unblock() to unblock a
> >>> POSIX task, without Xenomai realtime threads?
> >>>
> >>> The solution I provided is for the latter case.
> >>
> >>
> >>
> >> My original goal was to port a very complex realtime application from Xenomai 2.6.5 Native skin to Xenomai 3.1 POSIX skin. So I made series of examples, where I tried to verify porting of several designs used in the orig. application. And rt_task_unblock() for reconfiguration of the waiting threads in the orig app was one of them.
> >>
> >> Now I'm very curious, why the (my explicit) signals in Xenomai POSIX skin are not working for me as I would expect.
> >>
> >>
> >>
> >> Here is my compile command:
> >>
> >> g++ -fasynchronous-unwind-tables   -c -g -D_DEBUG -D_GNU_SOURCE -D_REENTRANT -D__COBALT_WRAP__ -D__COBALT__ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
> >>
> >>
> >>
> >> Here is my link command:
> >>
> >> g++ -fasynchronous-unwind-tables    -o dist/Debug/GNU-Linux/countertestapp_4 build/Debug/GNU-Linux/main.o -L/usr/xenomai/lib -Wl,-rpath,'/usr/xenomai/lib' -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -lcobalt -lmodechk -lpthread -lrt
> >>
> >>
> >>
> >> I'm using Netbeans IDE for my attemps, but the I tried to integrate xeno-config --posix --cflags or --ldflags result into the project settings as much as possible.
> >
> > Okay. Now things get clearer.
> > pthread_kill() will be wrapped to Xenomai, but you installed a signal
> > handler for a Linux process.
> >
> > What you basically need is a function in the Xenomai POSIX skin which
> > calls threadobj_unblock().
> >
>
> Below the working version for unblocking the RT task with non-RT signal.

This interrupts the Linux syscall, yes. Does this also work when the
thread blocks on the Xenomai/Cobalt side?

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 14.04.20 12:23, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 12:07 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 14.04.20 11:46, Richard Weinberger wrote:
>>> On Tue, Apr 14, 2020 at 11:11 AM Petr Červenka <grugh@centrum.cz> wrote:
>>>>
>>>>> I fear there seems to be a confusion between POSIX tasks and POSIX skin.
>>>>> Is your goal programming Xenomai realtime threads using POSIX alike APIs?
>>>>> Or are you looking for a pedant of rt_task_unblock() to unblock a
>>>>> POSIX task, without Xenomai realtime threads?
>>>>>
>>>>> The solution I provided is for the latter case.
>>>>
>>>>
>>>>
>>>> My original goal was to port a very complex realtime application from Xenomai 2.6.5 Native skin to Xenomai 3.1 POSIX skin. So I made series of examples, where I tried to verify porting of several designs used in the orig. application. And rt_task_unblock() for reconfiguration of the waiting threads in the orig app was one of them.
>>>>
>>>> Now I'm very curious, why the (my explicit) signals in Xenomai POSIX skin are not working for me as I would expect.
>>>>
>>>>
>>>>
>>>> Here is my compile command:
>>>>
>>>> g++ -fasynchronous-unwind-tables   -c -g -D_DEBUG -D_GNU_SOURCE -D_REENTRANT -D__COBALT_WRAP__ -D__COBALT__ -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
>>>>
>>>>
>>>>
>>>> Here is my link command:
>>>>
>>>> g++ -fasynchronous-unwind-tables    -o dist/Debug/GNU-Linux/countertestapp_4 build/Debug/GNU-Linux/main.o -L/usr/xenomai/lib -Wl,-rpath,'/usr/xenomai/lib' -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -lcobalt -lmodechk -lpthread -lrt
>>>>
>>>>
>>>>
>>>> I'm using Netbeans IDE for my attemps, but the I tried to integrate xeno-config --posix --cflags or --ldflags result into the project settings as much as possible.
>>>
>>> Okay. Now things get clearer.
>>> pthread_kill() will be wrapped to Xenomai, but you installed a signal
>>> handler for a Linux process.
>>>
>>> What you basically need is a function in the Xenomai POSIX skin which
>>> calls threadobj_unblock().
>>>
>>
>> Below the working version for unblocking the RT task with non-RT signal.
> 
> This interrupts the Linux syscall, yes. Does this also work when the
> thread blocks on the Xenomai/Cobalt side?
> 

That ::read is a Xenomai syscall, being handled in the end by 
timerfd_read in the core. So, yes.

There were two "tricks" needed: avoid syscall restart (as you already 
noticed) and using __STD (i.e. __real) pthread_kill in order to get a 
normal signal out. Oh, and the flag var should better be volatile, but 
that may still work when lucky.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 12:29 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > This interrupts the Linux syscall, yes. Does this also work when the
> > thread blocks on the Xenomai/Cobalt side?
> >
>
> That ::read is a Xenomai syscall, being handled in the end by
> timerfd_read in the core. So, yes.

True that, once again I got tricked by wrapping. :-)

> There were two "tricks" needed: avoid syscall restart (as you already
> noticed) and using __STD (i.e. __real) pthread_kill in order to get a
> normal signal out. Oh, and the flag var should better be volatile, but
> that may still work when lucky.

While we are here, is there a guarantee that rt_task_unblock() can unblock
a thread in every situation?
I have a large Xenomai 2 application on my desk which seems to assumes that.

As far as I understand it, unblocking tasks is best effort.
/me has pthread_mutex_lock() in mind which must not return -EINTR as
required by POSIX.

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 14.04.20 12:41, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 12:29 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> This interrupts the Linux syscall, yes. Does this also work when the
>>> thread blocks on the Xenomai/Cobalt side?
>>>
>>
>> That ::read is a Xenomai syscall, being handled in the end by
>> timerfd_read in the core. So, yes.
> 
> True that, once again I got tricked by wrapping. :-)
> 
>> There were two "tricks" needed: avoid syscall restart (as you already
>> noticed) and using __STD (i.e. __real) pthread_kill in order to get a
>> normal signal out. Oh, and the flag var should better be volatile, but
>> that may still work when lucky.
> 
> While we are here, is there a guarantee that rt_task_unblock() can unblock
> a thread in every situation?
> I have a large Xenomai 2 application on my desk which seems to assumes that.

IIRC, it does so for the native/alchemy API.

> 
> As far as I understand it, unblocking tasks is best effort.
> /me has pthread_mutex_lock() in mind which must not return -EINTR as
> required by POSIX.
> 

Well, when mixing APIs, you can end up in such conflicting goals, indeed.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> > While we are here, is there a guarantee that rt_task_unblock() can unblock
> > a thread in every situation?
> > I have a large Xenomai 2 application on my desk which seems to assumes that.
>
> IIRC, it does so for the native/alchemy API.
>
> >
> > As far as I understand it, unblocking tasks is best effort.
> > /me has pthread_mutex_lock() in mind which must not return -EINTR as
> > required by POSIX.
> >
>
> Well, when mixing APIs, you can end up in such conflicting goals, indeed.

I fear more about Xenomai internals which are now based on POSIX APIs.
IIRC we talked regarding this issue some time ago.

Found the mail:
https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 14.04.20 12:56, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>>> While we are here, is there a guarantee that rt_task_unblock() can unblock
>>> a thread in every situation?
>>> I have a large Xenomai 2 application on my desk which seems to assumes that.
>>
>> IIRC, it does so for the native/alchemy API.
>>
>>>
>>> As far as I understand it, unblocking tasks is best effort.
>>> /me has pthread_mutex_lock() in mind which must not return -EINTR as
>>> required by POSIX.
>>>
>>
>> Well, when mixing APIs, you can end up in such conflicting goals, indeed.
> 
> I fear more about Xenomai internals which are now based on POSIX APIs.
> IIRC we talked regarding this issue some time ago.
> 
> Found the mail:
> https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html

Indeed, there is a todo...

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Richard Weinberger]

On Tue, Apr 14, 2020 at 1:02 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 14.04.20 12:56, Richard Weinberger wrote:
> > On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >
> >>> While we are here, is there a guarantee that rt_task_unblock() can unblock
> >>> a thread in every situation?
> >>> I have a large Xenomai 2 application on my desk which seems to assumes that.
> >>
> >> IIRC, it does so for the native/alchemy API.
> >>
> >>>
> >>> As far as I understand it, unblocking tasks is best effort.
> >>> /me has pthread_mutex_lock() in mind which must not return -EINTR as
> >>> required by POSIX.
> >>>
> >>
> >> Well, when mixing APIs, you can end up in such conflicting goals, indeed.
> >
> > I fear more about Xenomai internals which are now based on POSIX APIs.
> > IIRC we talked regarding this issue some time ago.
> >
> > Found the mail:
> > https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html
>
> Indeed, there is a todo...

No big deal. I actually try hard to get rid of all rt_task_unblock()
users in our code base. :-)

-- 
Thanks,
//richard

Re: rt_task_unblock() POSIX alternative

[Jan Kiszka]

On 14.04.20 13:05, Richard Weinberger wrote:
> On Tue, Apr 14, 2020 at 1:02 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 14.04.20 12:56, Richard Weinberger wrote:
>>> On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>>>> While we are here, is there a guarantee that rt_task_unblock() can unblock
>>>>> a thread in every situation?
>>>>> I have a large Xenomai 2 application on my desk which seems to assumes that.
>>>>
>>>> IIRC, it does so for the native/alchemy API.
>>>>
>>>>>
>>>>> As far as I understand it, unblocking tasks is best effort.
>>>>> /me has pthread_mutex_lock() in mind which must not return -EINTR as
>>>>> required by POSIX.
>>>>>
>>>>
>>>> Well, when mixing APIs, you can end up in such conflicting goals, indeed.
>>>
>>> I fear more about Xenomai internals which are now based on POSIX APIs.
>>> IIRC we talked regarding this issue some time ago.
>>>
>>> Found the mail:
>>> https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html
>>
>> Indeed, there is a todo...
> 
> No big deal. I actually try hard to get rid of all rt_task_unblock()
> users in our code base. :-)
> 

Well, some fix is needed in any case, at least to the docs stating the 
rt_mutex_acquire* will return -EINTR when interrupted by 
rt_task_unblock. That is currently not true.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: rt_task_unblock() POSIX alternative

[Petr Červenka]

>    err = __STD(pthread_kill)(task, SIGUSR1);
>    if (err != 0) {
>        printf("pthread_kill failed: %d (%s)\n", err, strerror(-err));
>    }

 Thank you Jan. This is what I needed. You have alredy mentioned it in the past. But I just used the pthread_kill() and somehow totally missed the __STD() thing.
Petr