2

I've been developing C++ on Linux for a long time. And when I develop some independent module processing a message/task queue, I always process the SIGINT signal to avoid message/task loss. Here is an example of my code:

volatile sig_atomic_t sig = 0;

void sig_handler(int signal)
{
    sig = 1;
}

int main()
{
    signal(SIGINT,sig_handler);

    msg_queue = init_msg_queue();
    init_receiving_msg_thread();    // start a thread to receive msgs and push them into msg_queue
    while(!sig) {
        process_msg(msg_queue.top());    // process the first msg in the queue
        msg_queue.pop();    // remove the first msg
    }
    stop_receiving_msg_thread();
    process_all_msgs(msg_queue);
    return 0;
}

Well, this piece of code is simple: if the signal SIGINT is captured, stop receiving messages, process all of messages left in the queue and return. Otherwise, the code will stay in the infinite while.

I thought the sig_atomic_t was some black magic. Because as my understanding, the function sig_handler must be a reentrant function, meaning that it can't hold any static or global non-constant data: What exactly is a reentrant function?

So I always thought that sig_atomic_t was some tricky stuff, instead of a global variable.

But today I read this link: How does sig_atomic_t actually work?, which told me that sig_atomic_t is nothing but simply a typedef, such as an int. So it seems that sig_atomic_t sig is simply a global variable.

Now I'm confused.

Did my code above use sig_atomic_t correctly? If not, could you please show me a correct example? If my code is correct, what did I misunderstand? sig_atomic_t is not a global varible? Or a global variable can be used in a reentrant function? Or the function sig_handler can be non-reentrant function?

Yves
  • 11,597
  • 17
  • 83
  • 180

1 Answers1

0

Your use of volatile sig_atomic_t is correct.

The manpage for signal(3p) says the following:

   "the behavior is undefined if the signal handler refers to any
   object other than errno with static storage duration other than
   by assigning a value to an object declared as volatile
   sig_atomic_t," ...

So why does volatile sig_atomic_t have this ability while other variables are unsafe?

The link you provided actually answers that. "it is guaranteed to be read and written in one go." But to elaborate, sig_atomic_t is actually not an atomic type, however it essentially acts like one for signal interrupt purposes. But it is generally not suited for multithreading purposes so do not use it for inter-thread communication.

A true atomic type is actually specially handled by the CPU where it will make sure that only one core (cpu) can perform a whole operation (some manipulations take multiple instructions to complete) before another CPU (or process) can manipulate that data. sig_atomic_t on the other hand does not provide that hardware guarantee, but instead insures that any operation performed on it (read/write) will be done with a single instruction, thus the ability for a reentrant of that function to interrupt the completion of that value manipulation is eliminated.

StealthBadger747
  • 83
  • 5
  • Thanks. It helps. Now I explain this issue like this: `int` can be guaranteed to be read and written in one go. But other types, such as `long`, `CustomStruct` can't. In this case, people say: don't use any other global variable except `sig_atomic_t` in any reentrant function to make sure everything will be fine, developer needn't be very careful when using variable in a reentrant function with the help of `sig_atomic_t`. Maybe someday, `int` can't be guaranteed to be read and written in one go anymore, at that time, `sig_atomic_t` will not be the same with `int`... – Yves Jan 06 '21 at 08:21
  • I just found the source code about `sig_atomic_t`: https://code.woboq.org/userspace/glibc/signal/bits/types/sig_atomic_t.h.html, we can double-click on `__sig_atomic_t` and get its definition: `typedef int __sig_atomic_t;`. – Yves Jan 06 '21 at 08:23
  • Of course, as you said, `it is guaranteed to be read and written in one go` doesn't mean thread safe. I can understand this. – Yves Jan 06 '21 at 08:33
  • In regards to your first comment. I agree with your reasoning. But there are probably possibilities where on certain cpus, like maybe 8 bit cpus where int would be too large to handle with one instruction. Thus using this typedef makes it clear what should happen with this variable. Also I'd argue that it is just a good stylistic choice to use sig_atomic_t because it makes it clear that this is a safe use of the variable. – StealthBadger747 Jan 06 '21 at 09:07
  • I should also mention that the definition that you reference is only guaranteed in glibc. Although I'm sure most other libc implementations will have the same definition. However I am not sure if it is C standard or POSIX issue or not, which would mean it _should_ be the same everywhere. – StealthBadger747 Jan 06 '21 at 09:14
  • Exactly. I agree. – Yves Jan 06 '21 at 09:24