Accessing Shared Atomic Objects from within a Signal Handler in C
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The CERT® C Coding Standard, Second Edition: 98 Rules for Developing Safe, Reliable, and Secure Systems, Second Edition [1] will be published shortly. It has been updated for the C11 standard and for compatibility with the ISO/IEC TS 17961 C Secure Coding Rules. [2] The rule that gave me the most difficulty in this edition of the book was SIG31-C: "Do not access shared objects in signal handlers." This rule exists because accessing shared objects in signal handlers can result in race conditions that can leave data in an inconsistent state. In this article, I provide some additional background on accessing atomic objects from within a signal handler; I'll go beyond the description of the rule and the examples in the book.
This rule was present in the first edition of The CERT C Secure Coding Standard, but because the scope of that book was C99 and atomic objects were not yet defined, the only conforming way to access a shared object from a signal handler was to read from or write to variables of type volatile sig_atomic_t. The following conforming program installs a SIGINT handler that sets the volatile sig_atomic_t variable e_flag and then tests whether the handler was called before exiting:
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
volatile sig_atomic_t e_flag = 0;
void handler(int signum) {
e_flag = 1;
}
int main(void) {
if (signal(SIGINT, handler) == SIG_ERR) {
return EXIT_FAILURE;
}
/* Main code loop */
if (e_flag) {
puts("SIGINT received.");
}
else {
puts("SIGINT not received.");
}
return EXIT_SUCCESS;
}
C11, 5.1.2.3, paragraph 5 also allows for signal handlers to read from and write to lock-free atomic objects. [3] Following is a simple (but nonconforming) example of accessing an atomic flag. The atomic_flag type provides the classic test-and-set functionality. It has two states, set and clear, and the C Standard guarantees that operations on an object of type atomic_flag are lock-free.
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#if __STDC_NO_ATOMICS__ != 1
#include <stdatomic.h>
#endif
atomic_flag e_flag = ATOMIC_FLAG_INIT;
void handler(int signum) {
(void)atomic_flag_test_and_set(&e_flag);
}
int main(void) {
if (signal(SIGINT, handler) == SIG_ERR) {
return EXIT_FAILURE;
}
/* Main code loop */
if (atomic_flag_test_and_set(&e_flag)) {
puts("SIGINT received.");
}
else {
puts("SIGINT not received.");
}
return EXIT_SUCCESS;
}
The atomic_flag type is the only type that is guaranteed to be lock-free, provided that atomics are supported. The atomic_flag type is also the only type that is guaranteed to be accessible from a signal handler. However, objects of this type can be meaningfully accessed only by calls to atomic functions, and such calls are not permitted. According to the C Standard 7.14.1.1, paragraph 5, undefined behavior exists if the signal handler calls any function in the standard library other than the abort function; the _Exit function; the quick_exit function; or the signal function, with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler.
This limitation exists because most C library functions need not be asynchronous-safe. (See SIG30-C: "Call only asynchronous-safe functions within signal handlers" in The CERT® C Coding Standard, Second Edition.) To solve this problem without a change to the standard, we need to rewrite the example using a different atomic type, such as atomic_int:
#include <signal.h>
#include <stdlib.h>
#if __STDC_NO_ATOMICS__ != 1
#include <stdatomic.h>
#endif
atomic_int e_flag = ATOMIC_VAR_INIT(0);
void handler(int signum) {
e_flag = 1;
}
int main(void) {
if (signal(SIGINT, handler) == SIG_ERR) {
return EXIT_FAILURE;
}
/* Main code loop */
if (e_flag) {
puts("SIGINT received.");
}
else {
puts("SIGINT not received.");
}
return EXIT_SUCCESS;
}
This solution succeeds on platforms where the atomic_int type is always lock-free. The following code will cause the compiler to produce a diagnostic message if atomics are not supported or the atomic_int type is never lock-free:
#if __STDC_NO_ATOMICS__ == 1 #error "Atomics is not supported" #elif ATOMIC_INT_LOCK_FREE == 0 #error "int is never lock-free" #endif
The ATOMIC_INT_LOCK_FREE macro may have a value of 0, indicating that the type is never lock-free; a value of 1, indicating that the type is sometimes lock-free; or a value of 2, indicating that the type is always lock-free. If the type is sometimes lock-free, the atomic_is_lock_free function must be called at runtime to determine whether the type is lock-free:
#if ATOMIC_INT_LOCK_FREE == 1
if (!atomic_is_lock_free(&e_flag)) {
return EXIT_FAILURE;
}
#endif
Atomic types are sometimes lock-free because, for some architectures, some processor variants support lock-free compare-and-swap, while others don't (for example, 80386 vs. 80486). Depending on the processor variant, the application may be bound to a different dynamic library. Consequently, it is necessary to include a runtime check for implementations where ATOMIC_INT_LOCK_FREE == 1. This conforming program will work on implementations where the atomic_int type is lock-free:
#include <signal.h>
#include <stdlib.h>
#if __STDC_NO_ATOMICS__ != 1
#include <stdatomic.h>
#endif
#if __STDC_NO_ATOMICS__ == 1
#error "Atomics is not supported"
#elif ATOMIC_INT_LOCK_FREE == 0
#error "int is never lock-free"
#endif
atomic_int e_flag = ATOMIC_VAR_INIT(0);
void handler(int signum) {
e_flag = 1;
}
int main(void) {
#if ATOMIC_INT_LOCK_FREE == 1
if (!atomic_is_lock_free(&e_flag)) {
return EXIT_FAILURE;
}
#endif
if (signal(SIGINT, handler) == SIG_ERR) {
return EXIT_FAILURE;
}
/* Main code loop */
if (e_flag) {
puts("SIGINT received.");
}
else {
puts("SIGINT not received.");
}
return EXIT_SUCCESS;
}
One remaining question is why the e_flag variable is not declared volatile. Unlike the first example that used volatile sig_atomic_t, loads and stores of objects with atomic types are performed with memory_order_seq_cst semantics. Sequentially consistent programs behave as though the operations executed by their constituent threads are simply interleaved, with each value computation of an object being the last value stored in that interleaving. The arguments to the atomic operations are specified as volatile A * to allow atomic objects to be declared volatile, not to require it.
The C Standards Committee (WG14) has generally followed the lead of the C++ Standards Committee (WG21) in defining support for concurrency. The intent of the WG21 committee was to make lock-free atomics usable in signal handlers in C++11. [4] Unfortunately, some mistakes were made that WG21 is now trying to fix in C++14. The latest proposal to specify the behavior of signal handlers in C++ is WG21/N3910, [5] which resulted in the following text being added to the C++14 Draft International Standard:
A signal handler that is executed as a result of a call to the raise function belongs to the same thread of execution as the call to the raise function. Otherwise it is unspecified which thread of execution contains a signal handler invocation.
POSIX® [6] requires that a determination be made if a signal has been generated for the process or for a specific thread within the process. Signals that are generated by some action attributable to a particular thread, such as a hardware fault, are generated for the thread that caused the signal to be generated. Signals that are generated in association with a process ID, a process group ID, or an asynchronous event such as terminal activity, are generated for the process.
Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine. Actions on volatile objects cannot be optimized out by an implementation. Before atomic objects were available, volatile provided the closest approximation to the semantics required for an object shared by a signal handler. Atomics are now a better choice for accessing shared objects in signal handlers because volatile does not enforce visibility ordering with respect to other threads, making it exceedingly hard to specify how it works across threads. Consequently, volatile sig_atomic_t can be used to communicate only with a handler running in the same thread.
The C Standard does not allow signal handlers to be installed in multithreaded programs. Specifically, C11 states that the use of the signal function in a multithreaded program is undefined behavior, so much of the discussion of handling signals in multithreaded programs is moot for conforming C programs.
The following example is the most portable version of this program. Because type substitution is used in this example, everything must be known at compile time. The example uses atomics when the availability of a lock-free atomic type can be determined at compile time; otherwise, it uses volatile sig_atomic_t. Consequently, if ATOMIC_INT_LOCK_FREE == 1, it is treated the same as if it were zero.
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#if __STDC_NO_ATOMICS__ != 1
#include <stdatomic.h>
#endif
#if __STDC_NO_ATOMICS__ == 1
typedef volatile sig_atomic_t flag_type;
#elif ATOMIC_INT_LOCK_FREE == 0 || ATOMIC_INT_LOCK_FREE == 1
typedef volatile sig_atomic_t flag_type;
#else
typedef atomic_int flag_type;
#endif
flag_type e_flag;
void handler(int signum) {
e_flag = 1;
}
int main(void) {
if (signal(SIGINT, handler) == SIG_ERR) {
return EXIT_FAILURE;
}
/* Main code loop */
if (e_flag) {
puts("SIGINT received.");
}
else {
puts("SIGINT not received.");
}
return EXIT_SUCCESS;
}
According to the C Standard, "[T]he default (zero) initialization for objects with static or thread-local storage duration is guaranteed to produce a valid state," meaning that the e_flag object does not need to be initialized explicitly in this or any of the other examples.
Conclusions
Accessing shared objects from signal handlers is currently problematic for both C and C++ (which hopes to resolve these problems in C++14). Current opinion appears to be in favor of modifying the C Standard to allow atomic flag functions to be invoked from a signal handler, and such a proposal has been submitted to WG14. [7] The Austin Group is working on integrating C11 into POSIX for Issue 8. Because the use of the signal function in a multithreaded program is undefined behavior in C, POSIX can augment the language by providing a definition of the officially undefined behavior. In the long term, the C and C++ standards committees appear to be heading in the direction of abandoning volatile sig_atomic_t because it does not support multithreaded execution and because atomic types now provide a better alternative.