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
的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的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 typevolatile sig_atomic_t．的following conforming program installs aSIGINThandler that sets thevolatile sig_atomic_tvariablee_flagand then tests whether the handler was called before exiting:
#include#include #include 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. Theatomic_flagtype 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 typeatomic_flagare lock-free.
#include#include #include #if __STDC_NO_ATOMICS__ != 1 #include #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; }
的atomic_flagtype is the only type that is guaranteed to be lock-free, provided that atomics are supported. Theatomic_flagtype 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 theabortfunction; the_Exitfunction; thequick_exitfunction; or thesignalfunction, 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的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 asatomic_int:
#include#include #if __STDC_NO_ATOMICS__ != 1 #include #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 theatomic_inttype is always lock-free. The following code will cause the compiler to produce a diagnostic message if atomics are not supported or theatomic_inttype 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
的ATOMIC_INT_LOCK_FREEmacro may have a value of0, indicating that the type is never lock-free; a value of1, indicating that the type is sometimes lock-free; or a value of2, indicating that the type is always lock-free. If the type is sometimes lock-free, theatomic_is_lock_freefunction 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 aresometimeslock-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 whereATOMIC_INT_LOCK_FREE == 1．This conforming program will work on implementations where theatomic_inttype is lock-free:
#include#include #if __STDC_NO_ATOMICS__ != 1 #include #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 thee_flagvariable is not declared volatile. Unlike the first example that usedvolatile sig_atomic_t, loads and stores of objects with atomic types are performed withmemory_order_seq_cstsemantics. 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 asvolatile A *toallowatomic objects to be declaredvolatile, not torequireit.
的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 theraisefunction belongs to the same thread of execution as the call to theraisefunction. Otherwise it is unspecified which thread of execution contains asignalhandler 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 beoptimized out由一个implementation. Before atomic objects were available,volatileprovided 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 becausevolatiledoes not enforce visibility ordering with respect to other threads, making it exceedingly hard to specify how it works across threads. Consequently,volatile sig_atomic_tcan be used to communicate only with a handler running in the same thread.
的C Standard does not allow signal handlers to be installed in multithreaded programs. Specifically, C11 states that the use of thesignal函数在多线程程序定义behavior, so much of the discussion of handling signals in multithreaded programs is moot for conforming C programs.
的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 usesvolatile sig_atomic_t．因此,如果ATOMIC_INT_LOCK_FREE == 1, it is treated the same as if it were zero.
#include#include #include #if __STDC_NO_ATOMICS__ != 1 #include #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 thee_flagobject 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 thesignal函数在多线程程序定义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 abandoningvolatile sig_atomic_tbecause it does not support multithreaded execution and because atomic types now provide a better alternative.