<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en-us">

<HEAD>
<TITLE>N2459: Allow atomics use in signal handlers</title>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII" >
<table summary="Identifying information for this document.">
	<tr>
                <th>Doc. No.:</th>
                <td>WG21/N2459<br>
                J16/07-0329</td>
        </tr>
        <tr>
                <th>Date:</th>
                <td>2007-10-19</td>
        </tr>
        <tr>
                <th>Reply to:</th>
                <td>Hans-J. Boehm</td>
        </tr>
        <tr>
                <th>Phone:</th>
                <td>+1-650-857-3406</td>
        </tr>
        <tr>
                <th>Email:</th>
                <td><a href="mailto:Hans.Boehm@hp.com">Hans.Boehm@hp.com</a></td>
        </tr>
</table>

<H1>N2459: Allow atomics use in signal handlers</h1>
The atomics operations library (<A HREF="N2427.html">N2427</a>, accepted
into the working paper at the Kona meeting) was designed to support several
different applications:
<OL>
<LI>To communicate between threads in cases in which other synchronization
mechanisms such as locks are less appropriate.
<LI>To communicate between processes when other synchronization mechanisms
do not support it suitably.
<LI>To allow for communication with signal handlers.
</ol>
In the last case, locks are generally not usable since the signal
handler may have interrupted a thread holding a lock.  Depending on
whether the lock is reentrant, an attempt to acquire the lock in the
handler would either result in deadlock, or in two logically distinct
tasks acquiring the lock at the same time.
<P>
The first of the applications listed above is already supported by
N2427.  The second cannot really be addressed by the C++ standard.
Here we propose to allow the use of atomics in signal handlers, to the
extent that is under control of the C++ standard.
<P>
Our intent is to allow full use of atomic operations on atomic
object x in a signal
handler whenever atomic_is_lock_free(x) or x.is_lock_free() is true.
For example, in a Posix environment, these operations are intended to
be async-signal-safe.  But that is clearly beyond the scope of this standard.
<H2>Proposed wording changes</h2>
The current working paper gives rules for signal handler actions in two
places.  We propose to change them as follows:

<P>1.9p7:</p>
<BLOCKQUOTE>
When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects
<del>with type other
than <code>volatile std::sig_atomic_t</code></del>
<ins>which are neither</ins>
<UL>
<LI><ins>of type <code>volatile std::sig_atomic_t</code>, nor</ins>
<LI><ins>a lock-free atomic object (clause 29[atomics]), as
indicated by the <code>atomic_is_lock_free()</code>
or <code>is_lock_free()</code> functions,</ins>
</ul>
are unspecified, and the value of any object not
<del>of type <code>volatile std::sig_atomic_t</code></del>
<ins>in either of these two categories</ins>
that is modified by the handler becomes undefined.
</blockquote>

<P>18.8p6</p>
<BLOCKQUOTE>
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<ins>,
except that it may use functions defined in
clause 29[atomics], that are neither member functions
nor a members of a template class</ins>.
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 other function used
as a signal handler in a C++ program is implementation-defined.
</blockquote>
<P>
The second change is essentially a stopgap measure, which we expect
to become redundant when atomics are accepted into the C standard.
It is not clear that omitting the second change would cause real
problems, though it seems a bit safer to include it.
</body>
</html>

