|Reply to:||Hans-J. Boehm|
This is an attempt to summarize the current state of discussions around CWG issue 1441. Much of this discussion has occurred within SG1, and it has moved significantly past the original issue, so it seemed appropriate to turn it into a separate paper. This attempts to reflect the contributions of many people, especially Lawrence Crowl, Jens Maurer, Clark Nelson, and Detlef Vollmann.
This version is a minor revision of N3633. It reflects some changes due to SG1 concerns in Chicago, and reflects the easiest-to-address comments from the CWG discussion in Chicago. It does not reflect all of the latter. More discussion and almost certainly another paper revision is required.
CWG Issue 1441 points out that in the process of relaxing the restrictions on asynchronous signal handlers to allow use of atomics, we inadvertently made it impossible to use even local variables of non-volatile, non-atomic type. As a result of an initial discussion within CWG, Jens Maurer generated a proposed resolution, which addresses that specific issue.
Pre-Bristol discussion in SG1, both in Portland and during the February 2013 SG1 teleconference, raised a number of additional issues. Both Jens' solution and all prior versions of the standard still give undefined behavior to code involving signal handlers which we believe should clearly be legal. Our goal was to correct such oversights, and allow some realistic signal handlers to be portable, while preserving a significant amount of implementation freedom with respect to what is allowable in a signal handler. In particular, we do not want to reinvent Posix' notion of async-signal-safe functions here.
This issue was revisited as part of the concurrency group (SG1) meetings in Bristol. After some initial debate, that discussion concluded with several straw polls reaffirming that we want lock-free atomics to be usable in signal handlers, that signal handlers should be able to read data written before the handler installation, and that accesses to ordinary variables in signal handlers should be OK, so long as there are happens-before relationships separating such code from mainline code accesses. Some of us remember this as the original intent behind the C++11 changes, but recollections vary.
In spite of reaffirming the intent of this paper, the changes below were not brought forward as a change to the C++14 working paper, since there was a feeling we should take more time to consider alternate approaches to the wording, and that input from WG14 would be desirable.
My current hope is that something along the lines of this proposal, but probably not precisely these words, will find its way into the draft.
We give several proposed changes and summarize the reasoning behind the change as well as some of the past discussion:
Replace 1.9p6 [intro.execution]:
When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither
lock-free atomic objects (29.4) are unspecified during the execution of the signal handler, and the value of any object not in either of these two categories that is modified by the handler becomes undefined.
The original restriction would now be expressed elsewhere (see below) in terms of data races. This means that signal handlers can now access variables also accessed in mainline code, so long as the required happens-before orders are established.
We concluded during the February discussion that the old "interrupted by a signal" phrase referred to an asynchronous signal, and was basically OK. But after reading the C standard I'm not sure, and it makes sense to me to be more explicit. This is my latest attempt to do so.
Change one sentence in 1.9p15 [intro.execution]
If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.
This is a delicate area. Asynchronous signal handlers are unsequenced. If we said nothing else, even atomic operations in mainline code and the signal handler might introduce undefined behavior. We don't want that.
This is not an issue for regular unsequenced expressions. Consider the question of whether the following is legal:
atomic<int *>p = 0;
(i = 17, p = &i, 1) + (p? *p : 0);
After some false starts, we concluded in the February phone call that
the answer is yes, for reasons having more to do with function calls in
expressions than atomics.
The store to
p and the initial test of
are indeterminately sequenced. If the latter occurs first, the potentially
unsequenced access to
*p doesn't occur. In the other
case, the store to
i is sequenced before the store
p, which is sequenced before the test on
which is sequenced before the questionable load from
This again relies heavily on the fact that atomic operations are
function calls in C++. The situation in C is unfortunately different.
In spite of earlier contradictory conclusions, there are however strong reasons to treat unsequenced expressions differently from data races in signal handlers. These have to do with weaker memory orders. Consider the following example:
x = 1; y.store(1, memory_order_mo1);
if (y.load(memory_order_mo2)) tmp = x;
This should or should not result in undefined behavior, depending on mo1 and mo2. I don't think this is expressible without relying on happens-before.
Fortunately, I think this doesn't apply within expressions:
(x = 1, y.store(1, memory_order_relaxed), 0) + (y.load(memory_order_relaxed)? x : 1)
(all variables initially zero as usual)
must return 1. A compiler that violates this by reordering the initial
two stores and performing the
y.load() in the middle is broken.
(At least so we claim with only mild uncertainty.)
Thus the restriction on unsequenced operations should apply only to code that may not run concurrently. For code that may run concurrently (threads and signal handlers) we need the happens-before-based notion of data races that reflects memory_order specifications.
Change the normative part of 1.10p21 [intro.multithread] as follows:
The execution of a program contains a data race if it contains two conflicting actions
in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.
By the above reasoning, we need to give signal handlers the same data-race-based treatment as threads. Memory_order specifications must be respected in determining whether there is undefined behavior.
There was some discussion during the February phone call as to whether
we should view signal handlers as being performed by a specific thread at
all, and I think we were moving towards removing that notion.
A signal handler probably cannot portably tell which thread
it's running on. But after thinking about this more, I don't
know how to reconcile this change with
so I am once again inclined to leave things more like they are.
These changes should now have the effect of allowing full atomics to be used in communicating with a signal handler. I can now allocate an object, assign it to an atomic pointer variable, and have a signal handler access the non-atomic objects through that variable, just as another thread could. Since signal handlers obey strictly more scheduling constraints than threads, I think this is entirely expected, and what we had in mind all the time.
Insert in 18.10 [support.runtime] after p7:
This is necessary to allow signal handlers to access data that is read-only after installation of the handler. I expect this happens all the time already.
Note that 29.8p6 already talks about synchronizes-with relationships between a thread and a signal handler in the same thread, so I don't think this is a very fundamental change in perspective.
Change 18.10 [support.runtime] p9 as follows:
The common subset of the C and C++ languages consists of all declarations, definitions, and expressions that may appear in a well formed C++ program and also in a conforming C program. A POF ("plain old function") is a function that uses only features from this common subset, and that does not directly or indirectly use any function that is not a POF, except that it may use
functions defined in Clause 29 that are not member functions. All signal handlers shall have C linkage. A POF that could be used as a signal handler in a conforming C program does not produce undefined behavior when used as a signal handler in a C++ program.The behavior of any otherfunction used as a signal handler in a C++ program is implementation-defined.
Since we currently refer to C99 as the base document and C99 does not
thread_local, this somewhat accidentally prohibits
thread_local in signal handlers. Discussion in Bristol
suggests this may be a good thing, since
be implemented with a e.g. a locked hash table, which would result in
deadlocks if access from signal handlers were allowed.
Some of the earlier phone call discussion seems to have overlooked the existing
clause 29 exemption which, for example, makes calls to
That exemption was too broad, since it allowed non-lock-free calls. All calls that acquire locks need to be prohibited in signal handlers, since they typically deadlock if the mainline thread already holds the lock.
I don't understand the meaning of a normative sentence that says "X does not have undefined behavior". We otherwise define its meaning, so why would it possibly have undefined behavior without this sentence? Hence I'm proposing to rephrase.
(This paragraph removes the need for a 1.10p5 change I previously proposed.)