Merge 2017-03 CWG Motion 10

Author: zygoloid

source/basic.tex

@@ -2433,8 +2433,12 @@
 
 \pnum
 \indextext{program!start|(}%
-A program shall contain a global function called \tcode{main}, which is the designated
-start of the program. It is \impldef{defining \tcode{main} in freestanding environment}
+A program shall contain a global function called \tcode{main}.
+Executing a program starts a main thread of execution~(\ref{intro.multithread}, \ref{thread.threads})
+in which the \tcode{main} function is invoked,
+and in which variables of static storage duration
+might be initialized~(\ref{basic.start.static}) and destroyed~(\ref{basic.start.term}).
+It is \impldef{defining \tcode{main} in freestanding environment}
 whether a program in a freestanding environment is required to define a \tcode{main}
 function. \begin{note} In a freestanding environment, start-up and termination is
 \impldef{start-up and termination in freestanding environment}; start-up contains the
@@ -2546,7 +2550,8 @@
 \indextext{initialization!dynamic}%
 \defn{static initialization};
 all other initialization is \defn{dynamic initialization}.
-Static initialization shall be performed before any dynamic initialization takes place.
+All static initialization strongly happens before~(\ref{intro.races})
+any dynamic initialization.
 \begin{note} The dynamic initialization of non-local variables is described
 in~\ref{basic.start.dynamic}; that of local static variables is described
 in~\ref{stmt.dcl}. \end{note}
@@ -2612,14 +2617,28 @@
 \item
 If \tcode{V} has partially-ordered initialization, \tcode{W} does not have
 unordered initialization, and \tcode{V} is defined before \tcode{W} in
-every translation unit in which \tcode{W} is defined, the initialization of
-\tcode{V} is sequenced before the initialization of \tcode{W} if the
-program does not start a thread (\ref{intro.multithread}) and otherwise
-happens before the initialization of \tcode{W}.
+every translation unit in which \tcode{W} is defined, then
+\begin{itemize}
+\item
+if the program starts a thread~(\ref{intro.multithread})
+other than the main thread~(\ref{basic.start.main}),
+the initialization of \tcode{V}
+strongly happens before
+the initialization of \tcode{W};
+\item
+otherwise,
+the initialization of \tcode{V}
+is sequenced before
+the initialization of \tcode{W}.
+\end{itemize}
 
 \item
-Otherwise, if a program starts a thread before either \tcode{V} or \tcode{W} is
-initialized, the initializations of \tcode{V} and \tcode{W} are unsequenced.
+Otherwise, if the program starts a thread
+other than the main thread
+before either \tcode{V} or \tcode{W} is initialized,
+it is unspecified in which threads
+the initializations of \tcode{V} and \tcode{W} occur;
+the initializations are unsequenced if they occur in the same thread.
 
 \item
 Otherwise, the initializations of \tcode{V} and \tcode{W} are indeterminately sequenced.
@@ -2629,18 +2648,31 @@
 ordered variables concurrently with another sequence.
 \end{note}
 
+\pnum
+\indextext{non-initialization odr-use|see{odr-use, non-initialization}}%
+A \defnx{non-initialization odr-use}{odr-use!non-initialization}
+is an odr-use~(\ref{basic.def.odr}) not caused directly or indirectly by
+the initialization of a non-local static or thread storage duration variable.
+
 \pnum
 \indextext{evaluation!unspecified order of}%
-It is \impldef{dynamic initialization of static variables before \tcode{main}} whether the
-dynamic initialization of a non-local non-inline variable with static storage duration
-happens before the first statement of \tcode{main}. If the initialization is deferred to
-happen after the first statement of \tcode{main}, it happens before the
-first odr-use~(\ref{basic.def.odr}) of any non-inline function or non-inline variable
-defined in the same translation unit as the variable
-to be initialized.\footnote{A non-local variable with static storage duration
+It is \impldef{dynamic initialization of static variables before \tcode{main}}
+whether the dynamic initialization of a
+non-local non-inline variable with static storage duration
+is sequenced before the first statement of \tcode{main} or is deferred.
+If it is deferred, it strongly happens before
+any non-initialization odr-use
+of any non-inline function or non-inline variable
+defined in the same translation unit as the variable to be initialized.%
+\footnote{A non-local variable with static storage duration
 having initialization
-with side effects must be initialized even if it is not
-odr-used (\ref{basic.def.odr},~\ref{basic.stc.static}).}
+with side effects is initialized in this case,
+even if it is not itself odr-used (\ref{basic.def.odr},~\ref{basic.stc.static}).}
+It is \impldef{threads and program points at which deferred dynamic initialization is performed}
+in which threads and at which points in the program such deferred dynamic initialization occurs.
+\begin{note}
+Such points should be chosen in a way that allows the programmer to avoid deadlocks.
+\end{note}
 \begin{example}
 \begin{codeblock}
 // - File 1 -
@@ -2681,21 +2713,26 @@
 \pnum
 It is \impldef{dynamic initialization of static inline variables before \tcode{main}}
 whether the dynamic initialization of a
-non-local inline variable with static storage duration happens before the
-first statement of \tcode{main}. If the initialization is deferred
-to happen after the first statement of \tcode{main}, it happens before
-the first odr-use~(\ref{basic.def.odr}) of that variable.
+non-local inline variable with static storage duration
+is sequenced before the first statement of \tcode{main} or is deferred.
+If it is deferred, it strongly happens before
+any non-initialization odr-use
+of that variable.
+It is \impldef{threads and program points at which deferred dynamic initialization is performed}
+in which threads and at which points in the program such deferred dynamic initialization occurs.
 
 \pnum
 It is \impldef{dynamic initialization of thread-local variables before entry}
-whether the dynamic initialization of a non-local non-inline variable with static
-or thread storage duration is sequenced before
-the first statement of the initial function of the thread.
-If the initialization is deferred to some point in time sequenced after
-the first statement of the initial function of the thread,
-it is sequenced before the first odr-use~(\ref{basic.def.odr})
-of any non-inline variable with thread storage duration defined
-in the same translation unit as the variable to be initialized.
+whether the dynamic initialization of a
+non-local non-inline variable with thread storage duration
+is sequenced before the first statement of the initial function of a thread or is deferred.
+If it is deferred,
+the initialization associated with the entity for thread \placeholder{t}
+is sequenced before the first non-initialization odr-use by \placeholder{t}
+of any non-inline variable with thread storage duration
+defined in the same translation unit as the variable to be initialized.
+It is \impldef{threads and program points at which deferred dynamic initialization is performed}
+in which threads and at which points in the program such deferred dynamic initialization occurs.
 
 \pnum
 If the initialization of a non-local variable with static or thread storage duration
@@ -2711,24 +2748,34 @@
 \indextext{\idxcode{main} function!return from}%
 Destructors~(\ref{class.dtor}) for initialized objects
 (that is, objects whose lifetime~(\ref{basic.life}) has begun)
-with static storage duration
-are called as a result of returning from \tcode{main} and as a result of calling
+with static storage duration,
+and functions registered with \tcode{std::atexit},
+are called as part of a call to
 \indextext{\idxcode{exit}}%
 \indexlibrary{\idxcode{exit}}%
 \tcode{std::exit}~(\ref{support.start.term}).
+The call to \tcode{std::exit} is sequenced before
+the invocations of the destructors and the registered functions.
+\begin{note}
+Returning from \tcode{main} invokes \tcode{std::exit}~(\ref{basic.start.main}).
+\end{note}
+
+\pnum
 Destructors for initialized objects with thread storage duration within a given thread
 are called as a result of returning from the initial function of that thread and as a
 result of that thread calling \tcode{std::exit}.
 The completions of the destructors for all initialized objects with thread storage
-duration within that thread are sequenced before the initiation of the destructors of
+duration within that thread strongly happen before the initiation of the destructors of
 any object with static storage duration.
-If the completion of the constructor or dynamic initialization of an object with thread
-storage duration is sequenced before that of another, the completion of the destructor
-of the second is sequenced before the initiation of the destructor of the first.
+
+\pnum
 If the completion of the constructor or dynamic initialization of an object with static
+storage duration strongly happens before that of another, the completion of the destructor
+of the second is sequenced before the initiation of the destructor of the first.
+If the completion of the constructor or dynamic initialization of an object with thread
 storage duration is sequenced before that of another, the completion of the destructor
 of the second is sequenced before the initiation of the destructor of the first.
-\begin{note} This definition permits concurrent destruction. \end{note} If an object is
+If an object is
 initialized statically, the object is destroyed in the same order as if
 the object was dynamically initialized. For an object of array or class
 type, all subobjects of that object are destroyed before any block-scope
@@ -2750,13 +2797,13 @@
 \indextext{\idxcode{atexit}}%
 \indexlibrary{\idxcode{atexit}}%
 If the completion of the initialization of an object with static storage
-duration is sequenced before a call to \tcode{std::atexit}~(see
+duration strongly happens before a call to \tcode{std::atexit}~(see
 \tcode{<cstdlib>},~\ref{support.start.term}), the call to the function passed to
 \tcode{std::atexit} is sequenced before the call to the destructor for the object. If a
-call to \tcode{std::atexit} is sequenced before the completion of the initialization of
+call to \tcode{std::atexit} strongly happens before the completion of the initialization of
 an object with static storage duration, the call to the destructor for the
 object is sequenced before the call to the function passed to \tcode{std::atexit}. If a
-call to \tcode{std::atexit} is sequenced before another call to \tcode{std::atexit}, the
+call to \tcode{std::atexit} strongly happens before another call to \tcode{std::atexit}, the
 call to the function passed to the second \tcode{std::atexit} call is sequenced before
 the call to the function passed to the first \tcode{std::atexit} call.
 

source/intro.tex

@@ -795,23 +795,13 @@
 A conforming implementation executing a well-formed program shall
 produce the same observable behavior as one of the possible executions
 of the corresponding instance of the abstract machine with the
-same program and the same input. However, if any such execution contains an undefined operation, this International Standard places no
+same program and the same input.
+\indextext{behavior!undefined}%
+However, if any such execution contains an undefined operation, this International Standard places no
 requirement on the implementation executing that program with that input
 (not even with regard to operations preceding the first undefined
 operation).
 
-\indextext{behavior!unspecified}%
-\indextext{behavior!undefined}%
-\indextext{behavior!on receipt of signal}%
-\indextext{signal}%
-\pnum
-If a signal handler is executed as a result of a call to the \tcode{std::raise}
-function, then the execution of the handler is sequenced after the invocation
-of the \tcode{std::raise} function and before its return.
-\begin{note} When a signal is received for another reason, the execution of the
-signal handler is usually unsequenced with respect to the rest of the program.
-\end{note}
-
 \pnum
 An instance of each object with automatic storage
 duration~(\ref{basic.stc.auto}) is associated with each entry into its
@@ -1124,6 +1114,16 @@
 described above) are features of the function calls as evaluated,
 whatever the syntax of the expression that calls the function might be.%
 \indextext{value computation|)}%
+
+\indextext{behavior!on receipt of signal}%
+\indextext{signal}%
+\pnum
+If a signal handler is executed as a result of a call to the \tcode{std::raise}
+function, then the execution of the handler is sequenced after the invocation
+of the \tcode{std::raise} function and before its return.
+\begin{note} When a signal is received for another reason, the execution of the
+signal handler is usually unsequenced with respect to the rest of the program.
+\end{note}
 \indextext{program execution|)}
 
 \rSec1[intro.multithread]{Multi-threaded executions and data races}
@@ -1328,6 +1328,20 @@
 in the ``happens before'' relation. \begin{note} This cycle would otherwise be
 possible only through the use of consume operations. \end{note}
 
+\pnum
+An evaluation \placeholder{A} \defn{strongly happens before} an evaluation \placeholder{B}
+if either
+\begin{itemize}
+\item \placeholder{A} is sequenced before \placeholder{B}, or
+\item \placeholder{A} synchronizes with \placeholder{B}, or
+\item \placeholder{A} strongly happens before \placeholder{X} and \placeholder{X} strongly happens before \placeholder{B}.
+\end{itemize}
+\begin{note}
+In the absence of consume operations,
+the happens before and strongly happens before relations are identical.
+Strongly happens before essentially excludes consume operations.
+\end{note}
+
 \pnum
 A \defnx{visible side effect}{side effects!visible} \placeholder{A} on a scalar object or bit-field \placeholder{M}
 with respect to a value computation \placeholder{B} of \placeholder{M} satisfies the

source/support.tex

@@ -1785,7 +1785,9 @@
 function does not provide a handler for a thrown exception, \tcode{std::terminate()} shall
 be called.\indexlibrary{\idxcode{terminate}}
 \begin{note}
-\tcode{at_quick_exit} may call a registered function from a different thread
+A function registered via \tcode{at_quick_exit}
+is invoked by the thread that calls \tcode{quick_exit},
+which can be a different thread
 than the one that registered it, so registered functions should not rely on the identity
 of objects with thread storage duration.
 \end{note}