Signal handling slower when sleeping than spinning?

Question

I'm trying to understand why a signal is handled faster when the main process is spinning (while(1)) than sleeping.

I use the following code which creates a one-shot timer of 500us (based on How to implement highly accurate timers in Linux Userspace?) :

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/types.h>
#include <signal.h>
#include <unistd.h>

#define NSEC_PER_SEC 1000000000L

#define timerdiff(a,b) (((a)->tv_sec - (b)->tv_sec) * NSEC_PER_SEC + \
(((a)->tv_nsec - (b)->tv_nsec)))

struct timespec prev;

void handler( int signo )
{
    struct timespec now;
    unsigned long diff;

    clock_gettime(CLOCK_MONOTONIC, &now);
    diff = timerdiff(&now, &prev);

    printf("%lu\n", diff);

    exit(0);
}

int main(int argc, char *argv[])
{
    int i = 0;
    timer_t t_id;

    struct itimerspec tim_spec = {.it_interval= {.tv_sec=0,.tv_nsec=0},
                    .it_value = {.tv_sec=0,.tv_nsec=500000}};

    struct sigaction act;
    sigset_t set;

    sigemptyset( &set );
    sigaddset( &set, SIGALRM );

    act.sa_flags = 0;
    act.sa_mask = set;
    act.sa_handler = &handler;

    sigaction( SIGALRM, &act, NULL );

    if (timer_create(CLOCK_MONOTONIC, NULL, &t_id))
        perror("timer_create");

    clock_gettime(CLOCK_MONOTONIC, &prev);

    if (timer_settime(t_id, 0, &tim_spec, NULL))
        perror("timer_settime");

#ifdef SLEEP
    while(1)
        sleep(1);
#else
    while(1);
#endif

    return 0;
}

If the code is executed with SLEEP defined, 10 executions give me:

If SLEEP in not defined, the code will spin and I get those timings :

That's really better.

Can someone explain me? Getting out of sleep is slower than interrupting a spinning loop?

It tried this code on a Linux 4.9 PREEMPT_RT patched kernel on an Intel platform (8 cores), system is idle.

Thanks!

Aurélien

Note that you can not safely call `printf()` and `exit()` from within a signal handler. Per [**7.1.4 Use of library functions**, p4](https://port70.net/~nsz/c/c11/n1570.html#7.1.4p4): "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." [Footnote 188](https://port70.net/~nsz/c/c11/n1570.html#note188) adds: "Thus, a signal handler cannot, in general, call standard library functions." POSIX allows for calling async-signal-safe functions, but neither `printf()` nor `exit()` are async-signal-safe. — Andrew Henle, Dec 17 '19 at 11:02
(cont) See [**2.4 Signal Concepts**](https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04) — Andrew Henle, Dec 17 '19 at 11:04
@AndrewHenle But if you can rule out, that another function using stdio is interrupted by the signal, it should be relatively safe (safe enough for debugging/testing at least). — Ctx, Dec 17 '19 at 11:05
@AndrewHenle Thanks, that was just a quick'n'dirty sample code :) — Aurelien Imj, Dec 17 '19 at 11:57

score 4 · Accepted Answer · answered Dec 17 '19 at 10:54

4

When spinning, the kernel does not need to prepare the process to run, since the process is already running when the signal arrives. It just has to alter the instruction pointer to enter the signal handler.

If the process sleeps, it has to be put on the task queue, the context has to be restored (registers, memory mappings) and a whole lot of other preparatory steps until the process really runs.

This makes a small difference, but if you look at the total numbers, it is only about 10 - 100 µs in total.

answered Dec 17 '19 at 10:54

Ctx

18,090
24
36
51

There is the possibility that the process is running but not currently in execution though, right? In that case, won't there be the need for a context switch anyway? – Saucy Goat Dec 17 '19 at 11:00
@SaucyGoat Well, if the system is mostly idle and you have several cores, then the process is running almost for sure, when you use the spinning-method. If it is not, then a context switch is necessary, yes. – Ctx Dec 17 '19 at 11:01

Signal handling slower when sleeping than spinning?

1 Answers1