<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<title>C++ Data-Dependency Ordering: Memory Model</title>
</head><body>
<h1>C++ Data-Dependency Ordering: Memory Model</h1>

<p>ISO/IEC JTC1 SC22 WG21 N2360 = 07-0220 - 2007-08-04

</p><p>Paul E. McKenney, paulmck@linux.vnet.ibm.com

</p><h2>Introduction</h2>

<p> This document presents the memory-model implications of dependency
ordering, which is further described in
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html">N2359</A> and
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2361.html">N2361</A>.
The rationale for this proposal may be found in
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html">N2359</A>.
<P>
<P>
This proposal is based on
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2153.pdf">N2153</A>
by Silvera, Wong, McKenney, and Blainey, on
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html">N2176</A>
by Hans Boehm, on
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2195.html">N2195</A>
by Peter Dimov, on
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2260.html">N2260</A>
by Paul E. McKenney, on
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.html">N2334</A>
by Clark Nelson and Hans Boehm, on
discussions on the
cpp-threads list, and on discussions
in the concurrency workgroup at the 2007 Oxford and Toronto meetings.

<h3>Rationale</h3>

<P>
See <A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html">N2359</A>.

<h3>Prior Approaches</h3>

<P>
See <A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html">N2359</A>.


<h3>Dependency Chains</h3>

<P>
See <A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html">N2359</A>.


<h3>Current Approach</h3>

<P>
As noted earlier, this proposal is based on 
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.html">N2334</A>,
which is under active revision.
Therefore, the rest of this document must be considered a work in progress.
In any case, the general approach is to define dependency ordering in
terms of the modification order of a given object.
We cannot leverage happens before or synchronizes with because doing
so would introduce spurious ordering constraints that are inconsistent
with data dependency ordering.
</P>

<P> First, we define "dependency-synchronizes with":</P>

<BLOCKQUOTE><P>
	An evaluation A that performs a release operation on an object
	M <I>dependency-synchronizes with</I> an evaluation B that
	performs a dependency operation on M and reads a value written
	by any side effect in the release sequence headed by A.
</P></BLOCKQUOTE>

<P> Next, we define "dependency tree" (or, perhaps more accurately,
attempt to do so):</P>

<BLOCKQUOTE><P>
	An evaluation H that performs a dependency operation on an object
	M heads a dependency tree, and is also a member of that
	dependency tree.
	Any subsequent evaluation that consumes the result of a prior
	evaluation that is a member of H's dependency tree is also
	a member of H's dependency tree, unless that prior evaluation is
	an unannotated formal parameter or is a return value from a
	function whose function prototype specifies an unannotated
	return value.
	[<I>Note:</I> dependency annotations are described in
<A HREF="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2361.html">N2361</A>.]
	[<I>Note:</I> a given evaluation can be a member of multiple
	dependency trees.]
</P></BLOCKQUOTE>

<P>Finally, we present the data-dependency constraints:</P>

<OL>
<LI>	Load-to-load constraint:

	<BLOCKQUOTE><P>
		If a value computation A of object M happens before a
		release operation X that dependency-synchronizes with
		an evaluation H, and if evaluation H's dependency tree
		contains a value computation B of object M, then the
		value computed by B must either be the same as that
		computed by A or shall correspond to a value stored
		by a side-effect Y that occurs
		later than A in M's modification order.
	</P></BLOCKQUOTE>

<LI>	Load-to-store constraint:

	<BLOCKQUOTE><P>
		If a value computation A of object M happens before a
		release operation X that dependency-synchronizes with
		an evaluation H, and if evaluation H's dependency tree
		contains a side effect Y that modifies object M, then the
		value computed by A shall precede that stored by Y
		in M's modification order.
	</P></BLOCKQUOTE>

<LI>	Store-to-load constraint:

	<BLOCKQUOTE><P>
		If a side effect X that modifies object M happens before
		a release operation Y that dependency-synchronizes with
		an evaluation H, and if evaluation H's dependency tree
		contains a value computation B of M, then the value
		computed by B shall either equal the value stored by
		side effect X, or be the value stored by some side effect Z
		that modifies M,
		where Z follows X in the modification order of M.
	</P></BLOCKQUOTE>

<LI>	Store-to-store constraint:

	<BLOCKQUOTE><P>
		If a side-effect X that modifies object M happens before a
		release operation Y that dependency-synchronizes with
		an evaluation H, and if evaluation H's dependency tree
		contains a side effect Z that also modifies object M, then
		Z must follow X in M's modification order.
	</P></BLOCKQUOTE>
</OL>

</body></html>
