<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>P1239R0: Placed Before</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-left: calc(13px + 26.5rem - 50vw);
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-left: calc(40em - 50vw) !important;
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-left: 0 !important;
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
<style type="text/css">
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }
  </style>
  <meta content="Bikeshed version dff342f4b23fb230b71436fb31b55f5f169715bd" name="generator">
  <link href="http://wg21.link/P1239" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="d450395090a777c498ede7fa3bc86f84ec7cea6a" name="document-revision">
<style type="text/css">
.added {
  color: green;
}
.deleted {
  color: red;
  text-decoration: line-through;
}
.fixme {
  color: red;
}
</style>
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P1239R0<br>Placed Before</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2018-10-07">2018-10-07</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="http://wg21.link/P1239">http://wg21.link/P1239</a>
     <dt>Author:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:dlustig@nvidia.com">Daniel Lustig</a> (<span class="p-org org">NVIDIA</span>)
     <dt>Audience:
     <dd>SG1
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Source:
     <dd><a href="https://github.com/daniellustig/P1239/blob/master/placed-before.bs">https://github.com/daniellustig/P1239/blob/master/placed-before.bs</a>
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>Adding "placed before" to C++</p>
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#overview"><span class="secno">1</span> <span class="content">Overview</span></a>
    <li><a href="#old-word"><span class="secno">2</span> <span class="content">Wording as of C++17</span></a>
    <li><a href="#pb"><span class="secno">3</span> <span class="content">"Placed Before"</span></a>
    <li><a href="#fine-grained"><span class="secno">4</span> <span class="content">Fine-Grained Thread-Local Ordering</span></a>
    <li>
     <a href="#repairing-oota"><span class="secno">5</span> <span class="content">Repairing Out-Of-Thin-Air</span></a>
     <ol class="toc">
      <li><a href="#preventing-oota"><span class="secno">5.1</span> <span class="content">Using Annotations to Prevent OOTA</span></a>
      <li><a href="#ub"><span class="secno">5.2</span> <span class="content">Cycles of Unenforced Dependencies Result in Loads Returning Unspecified Values</span></a>
      <li><a href="#ofpb"><span class="secno">5.3</span> <span class="content">The "OOTA-Free-for-Placed-Before" Theorem</span></a>
     </ol>
    <li><a href="#consequences"><span class="secno">6</span> <span class="content">Consequences for Existing Code</span></a>
    <li>
     <a href="#examples"><span class="secno">7</span> <span class="content">Examples</span></a>
     <ol class="toc">
      <li><a href="#lb"><span class="secno">7.1</span> <span class="content">Load Buffering</span></a>
      <li><a href="#histogram"><span class="secno">7.2</span> <span class="content">Histogram</span></a>
      <li><a href="#rfub"><span class="secno">7.3</span> <span class="content">"Reads-from-untaken-branch"</span></a>
     </ol>
    <li><a href="#future"><span class="secno">8</span> <span class="content">Future work</span></a>
    <li><a href="#ack"><span class="secno">9</span> <span class="content">Acknowledgements</span></a>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="overview"><span class="secno">1. </span><span class="content">Overview</span><a class="self-link" href="#overview"></a></h2>
   <p>There has been much interest in supporting lightweight, fine-grained memory ordering for syntactic dependencies in C++.
Support for such ordering theoretically exists in the form of <code class="highlight"><c- n>memory_order_consume</c-></code>, but as is now well known, no compiler to date has been able to support such behavior.
This has been discussed in many previous papers, e.g., <a data-link-type="biblio" href="#biblio-p0098r1">[p0098r1]</a>, <a data-link-type="biblio" href="#biblio-p0190r3">[p0190r3]</a>, <a data-link-type="biblio" href="#biblio-p0462r1">[p0462r1]</a>.</p>
   <p>A related and notoriously difficult issue is the so-called "out-of-thin-air" (OOTA) problem: computations that somehow circularly depend on themselves can be made to return any arbitrary value, with the circular dependency causing speculation to become self-satisfying.  This has also been discussed in many previous papers, e.g., <a data-link-type="biblio" href="#biblio-n3710">[n3710]</a>, <a data-link-type="biblio" href="#biblio-ghosts">[ghosts]</a>.
The current C++ specification <a data-link-type="biblio" href="#biblio-n4750">[n4750]</a> places the burden of avoiding OOTA on the implementation:</p>
   <blockquote> Implementations should ensure that no "out-of-thin-air" values are computed that circularly depend on their own computation. </blockquote>
    In modern practice, it is generally considered impractical for implementations to enforce this guarantee, and so although research in the area continues, the current specification wording is considered insufficient. 
   <p>Previous papers and discussions have suggested various solutions to the dependency ordering and OOTA problems.
One approach, from <a data-link-type="biblio" href="#biblio-n3710">[n3710]</a> and elsewhere, is to globally enforce all atomic-load-to-atomic-store ordering.
A finer-grained variant of this approach is to introduce a <code class="highlight"><c- n>memory_order_load_store</c-></code> that is intermediate in strength between <code class="highlight"><c- n>memory_order_relaxed</c-></code> and <code class="highlight"><c- n>memory_order_acquire</c-></code>.
(Alternatively, <code class="highlight"><c- n>memory_order_relaxed</c-></code> might be required to enforce load-to-store ordering, and a new <code class="highlight"><c- n>memory_order</c-></code> would be introduced to provide the unsafe weaker behavior where appropriate.)
However, this approach has two drawbacks: 1) particularly in the first variant, it will overconstrain the implementation in cases not prone to OOTA, and 2) it does not capture load-to-load dependency ordering semantics.
A second class of solution involves building libraries that play clever tricks with inline assembly in order to propagate dependencies through the compiler; this was discussed in <a data-link-type="biblio" href="#biblio-p0750r1">[p0750r1]</a> and partially implemented in <a data-link-type="biblio" href="#biblio-webkit">[WebKit]</a>, for example.
This approach shows that libraries may be able to enforced fine-grained load-to-load and/or load-to-store dependency ordering, albeit at the cost of requiring a more complex API that <code class="highlight"><c- n>memory_order_consume</c-></code> alone would require.</p>
   <p>Our "placed-before" proposal attempts to integrate fine-grained dependency ordering enforcement mechanisms into the C++ memory model, as follows:</p>
   <ul>
    <li data-md>
     <p><b>Fine-grained intra-thread memory ordering annotations</b>: We define a new order "placed before" that captures any and all intra-thread ordering semantics that the implementation is known to be able to maintain, including any or all of the proposals discussed above.  Then, to first order, we perform a search and replace of "carries a dependency to" (which has proven impractical to use) with "placed before" (which is both more generic and more practical) in order to integrate "placed before" cleanly into the existing model.</p>
    <li data-md>
     <p><b>A fix for OOTA</b>: We define "carries an unenforced dependency to" to include any "carries a dependency to" ordering that does not overlap "placed before".  Then, we declare that loads caught in a cycle of "reads-from" and "carries an unenforced dependency to" (i.e., in an OOTA-prone execution) return unspecified values.  This approach shifts the burden of avoiding OOTA from the implementation to the programmer, and better reflects the reality of today’s implementations.</p>
   </ul>
   <h2 class="heading settled" data-level="2" id="old-word"><span class="secno">2. </span><span class="content">Wording as of C++17</span><a class="self-link" href="#old-word"></a></h2>
   <p>For reference, we quote the relevant wording as currently stated in <a data-link-type="biblio" href="#biblio-n4750">[n4750]</a>.</p>
   <p>Section 6.8.2.1 [intro.races] paragraph 7 defines "carries a dependency":</p>
   <blockquote>
     An evaluation A carries a dependency to an evaluation B if 
    <ul>
     <li data-md>
      <p>the value of A is used as an operand of B, unless:</p>
      <ul>
       <li data-md>
        <p>B is an invocation of any specialization of std::kill_dependency (32.4), or</p>
       <li data-md>
        <p>A is the left operand of a built-in logical AND (&amp;&amp;, see 8.5.14) or logical OR (||, see 8.5.15) operator, or</p>
       <li data-md>
        <p>A is the left operand of a conditional (?:, see 8.5.16) operator, or</p>
       <li data-md>
        <p>A is the left operand of the built-in comma (,) operator (8.5.19); or</p>
      </ul>
     <li data-md>
      <p>A writes a scalar object or bit-field M, B reads the value written by A from M, and A is sequenced before B, or</p>
     <li data-md>
      <p>for some evaluation X, A carries a dependency to X, and X carries a dependency to B.</p>
    </ul>
    <p>[ Note: "Carries a dependency to" is a subset of "is sequenced before", and is similarly strictly intra-thread.  —end note ]</p>
   </blockquote>
   <p>The definition of "carries a dependency to" continues to evolve and to be debated.  See, e.g., <a data-link-type="biblio" href="#biblio-p0190r3">[p0190r3]</a> for further discussion.  To the best of our knowledge, our proposal is compatible with any and all such changes, since the implementation is <i>not</i> required to track it under our proposal.</p>
   <p>Section 6.8.2.1 [intro.races] paragraphs 8-10 define how "carries a dependency to" feeds into "dependency-ordered before", "inter-thread happens before", and "happens before":</p>
   <blockquote>
    <p>An evaluation A is dependency-ordered before an evaluation B if</p>
    <ul>
     <li data-md>
      <p>A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or</p>
     <li data-md>
      <p>for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.</p>
    </ul>
    <p>[ Note: The relation "is dependency-ordered before" is analogous to "synchronizes with", but uses release/consume in place of release/acquire. —end note ]</p>
    <p>An evaluation A inter-thread happens before an evaluation B if</p>
    <ul>
     <li data-md>
      <p>A synchronizes with B, or</p>
     <li data-md>
      <p>A is dependency-ordered before B, or</p>
     <li data-md>
      <p>for some evaluation X</p>
      <ul>
       <li data-md>
        <p>A synchronizes with X and X is sequenced before B, or</p>
       <li data-md>
        <p>A is sequenced before X and X inter-thread happens before B, or</p>
       <li data-md>
        <p>A inter-thread happens before X and X inter-thread happens before B.</p>
      </ul>
    </ul>
    <p>[ Note: The "inter-thread happens before" relation describes arbitrary concatenations of "sequenced before", "synchronizes with" and "dependency-ordered before" relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with "dependency-ordered before" followed by "sequenced before". The reason for this limitation is that a consume operation participating in a "dependency-ordered before" relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency. The reason that this limitation applies only to the end of such a concatenation is that any subsequent release operation will provide the required ordering for a prior consume operation. The second exception is that a concatenation is not permitted to consist entirely of "sequenced before". The reasons for this limitation are (1) to permit "inter-thread happens before" to be transitively closed and (2) the "happens before" relation, defined below, provides for relationships consisting entirely of "sequenced before". —end note ]</p>
    <p>An evaluation A happens before an evaluation B (or, equivalently, B happens after A) if:</p>
    <ul>
     <li data-md>
      <p>A is sequenced before B, or</p>
     <li data-md>
      <p>A inter-thread happens before B.</p>
    </ul>
    <p>The implementation shall ensure that no program execution demonstrates a cycle in the "happens before" relation. [ Note: This cycle would otherwise be possible only through the use of consume operations. —end note ]</p>
   </blockquote>
   <p>Section 32.4 [atomics.order] paragraph 1.3 describes the current status of <code class="highlight"><c- n>memory_order_consume</c-></code>:</p>
   <blockquote> memory_order::consume: a load operation performs a consume operation on the affected memory location. [ Note: Prefer memory_order::acquire, which provides stronger guarantees than memory_order::consume. Implementations have found it infeasible to provide performance better than that of memory_order::acquire. Specification revisions are under consideration. —end note ] </blockquote>
   <p>Section 32.4 [atomics.order] paragraphs 9-10 describe out-of-thin-air values:</p>
   <blockquote>
     Implementations should ensure that no "out-of-thin-air" values are computed that circularly depend on their own computation.
[ Note: For example, with x and y initially zero, 
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
    <p>should not produce r1 == r2 == 42, since the store of 42 to y is only possible if the store to x stores 42, which circularly depends on the store to y storing 42. Note that without this restriction, such an execution is possible. —end note ]</p>
    <p>[ Note: The recommendation similarly disallows r1 == r2 == 42 in the following example, with x and y again initially zero:</p>
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>if</c-> <c- p>(</c-><c- n>r1</c-> <c- o>==</c-> <c- mi>42</c-><c- p>)</c-> <c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- mi>42</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>if</c-> <c- p>(</c-><c- n>r2</c-> <c- o>==</c-> <c- mi>42</c-><c- p>)</c-> <c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- mi>42</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
    <p>—end note ]</p>
   </blockquote>
   <h2 class="heading settled" data-level="3" id="pb"><span class="secno">3. </span><span class="content">"Placed Before"</span><a class="self-link" href="#pb"></a></h2>
   <p>"Placed before" is a new relation that captures any user-enforced intra-thread ordering.  We define "placed before" as follows:</p>
   <blockquote> <span class="added"> An evaluation A is placed before an evaluation B if A is sequenced before B and one or more of the following hold: <ul><li data-md><p>A is an acquire operation, and A is sequenced before B</p> </li><li data-md><p>A is a load, A is sequenced before an acquire fence F, and F is sequenced before B</p> </li><li data-md><p>A is sequenced before a release fence F, F is sequenced before B, and B is a store</p> </li><li data-md><p>A is sequenced before B, and B is a release operation</p> </li><li data-md><p>A is a consume operation, and A carries a dependency to B</p> </li></ul> <p>[ Note: "Placed before" is a subset of "sequenced before", and is similarly strictly intra-thread.  —end note ] </p> </span></blockquote>
   <p>The consume operation is included here for completeness.  If <code class="highlight"><c- n>memory_order_consume</c-></code> is deprecated, it can simply be removed.  If <code class="highlight"><c- n>memory_order_consume</c-></code> is promoted to <code class="highlight"><c- n>memory_order_acquire</c-></code> following standard practice today, then it simply overlaps with the first bullet.  If (magically) someone were to make <code class="highlight"><c- n>memory_order_consume</c-></code> work as originally intended, then its inclusion into "placed before" would allow it to continue serving its exact original purpose.  The rest of this proposal is agnostic to any of these options.</p>
   <p>The "placed before" formulation admits any number of fine-grained, thread-local ordering mechanisms.  Examples of future inclusions into "placed before" might include (possibly seven letter variants of):</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- n>memory_order_load_load</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>memory_order_load_store</c-></code></p>
    <li data-md>
     <p>Ideas such as the <code class="highlight"><c- n>dependent</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> class in <a data-link-type="biblio" href="#biblio-p0750r1">[p0750r1]</a></p>
    <li data-md>
     <p>Read-copy-update libraries</p>
   </ul>
   <p>All of these may be useful in certain cases as lighter-weight alternatives to <code class="highlight"><c- n>memory_order_acquire</c-></code> where the ordering needs are known to be finer-grained.  The <code class="highlight"><c- n>memory_order_load_store</c-></code> annotation would serve as a safe OOTA-free default, as discussed in <a href="#ofpb">§5.3 The "OOTA-Free-for-Placed-Before" Theorem</a>.  Examples for the <code class="highlight"><c- n>memory_order_load_load</c-></code> might include uses of <code class="highlight"><c- n>smp_rmb</c-><c- p>()</c-></code> in Linux.</p>
   <h2 class="heading settled" data-level="4" id="fine-grained"><span class="secno">4. </span><span class="content">Fine-Grained Thread-Local Ordering</span><a class="self-link" href="#fine-grained"></a></h2>
   <p>Although implementations have been unable to track dependencies being carried through code, the "carries a dependency to" relation itself appears to remain a good fit within the broader memory model.
As such, we propose to simply replace "carries a dependency to" with "is placed before", and then to adjust other rule definitions accordingly, as described below.</p>
   <p>By analogy to "dependency-ordered before", we define a new relation "inter-thread-placed before" that pairs release operations with "placed before".  To do this, we duplicate the definition of "dependency-ordered before" from Section 6.8.2.1 paragraph 9 and modify it as follows:</p>
   <blockquote>
     An evaluation A is <span class="deleted">dependency-ordered before</span> <span class="added">inter-thread-placed before</span> an evaluation B if 
    <ul>
     <li data-md>
      <p>A performs a release operation on an atomic object M, and, in another thread, B <span class="deleted">performs a consume operation on M and</span> reads a value written by any side effect in the release sequence headed by A, or</p>
     <li data-md>
      <p>for some evaluation X, A is <span class="deleted">dependency-ordered before</span> <span class="added">inter-thread-placed before</span> X and X <span class="deleted">carries a dependency to</span> <span class="added">is placed before</span> B.</p>
    </ul>
    <p>[ Note: The relation <span class="deleted">"dependency-ordered before"</span> <span class="added">"inter-thread-placed before"</span> is analogous to "synchronizes with", but uses <span class="deleted">release/consume</span> <span class="added">release and placed before</span> in place of release/acquire. —end note ]</p>
   </blockquote>
   <p>(Side note: <a data-link-type="biblio" href="#biblio-p0735r0">[p0735r0]</a> proposes to replace <span class="deleted">"a value written by any side effect in the release sequence headed"</span> with <span class="added">"the value written"</span>.  To the best of our knowledge, our proposal is agnostic to this change.)</p>
   <p>We then replace "dependency-ordered before" with "inter-thread-placed before" in Section 6.8.2.1 paragraph 9:</p>
   <blockquote>
     An evaluation A inter-thread happens before an evaluation B if 
    <ul>
     <li data-md>
      <p>A synchronizes with B, or</p>
     <li data-md>
      <p>A is <span class="deleted">dependency-ordered before</span> <span class="added">inter-thread-placed before</span> B, or</p>
     <li data-md>
      <p>for some evaluation X</p>
      <ul>
       <li data-md>
        <p>A synchronizes with X and X is sequenced before B, or</p>
       <li data-md>
        <p>A is sequenced before X and X inter-thread happens before B, or</p>
       <li data-md>
        <p>A inter-thread happens before X and X inter-thread happens before B.</p>
      </ul>
    </ul>
    <p>[ Note: The "inter-thread happens before" relation describes arbitrary concatenations of "sequenced before", "synchronizes with" and <span class="deleted">"dependency-ordered before"</span> <span class="added">"inter-thread-placed before"</span> relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with <span class="deleted">"dependency-ordered before"</span> <span class="added">"inter-thread-placed before"</span> followed by "sequenced before". The reason for this limitation is that <span class="deleted">a consume operation participating in a "dependency-ordered before" relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency</span> <span class="added">an atomic operation participating in a "placed before" relationship provides ordering only with respect to those specific operations that it is "placed before"</span>. The reason that this limitation applies only to the end of such a concatenation is that any subsequent release operation will provide the required ordering for a prior <span class="deleted">consume operation</span> <span class="added">atomic operation at the head of a "placed before" relation</span>. The second exception is that a concatenation is not permitted to consist entirely of "sequenced before". The reasons for this limitation are (1) to permit "inter-thread happens before" to be transitively closed and (2) the "happens before" relation, defined below, provides for relationships consisting entirely of "sequenced before". —end note ]</p>
   </blockquote>
   <p>Now, any form of "placed before" can be used where "carries a dependency to" would have been used before.</p>
   <h2 class="heading settled" data-level="5" id="repairing-oota"><span class="secno">5. </span><span class="content">Repairing Out-Of-Thin-Air</span><a class="self-link" href="#repairing-oota"></a></h2>
   <p>The "placed before" relation also provides the programmer with a means of preventing out-of-thin-air executions.
If a carried dependency might form an OOTA cycle, the user is responsible for ensuring that the head of the dependency is "placed before" any subsequent use of the carried dependency.
Alternatively, if the programmer fails to insert annotations sufficient to prevent a possible OOTA cycle, then the loads in the cycle will be declared to return unspecified values.
We fill in the details below.</p>
   <h3 class="heading settled" data-level="5.1" id="preventing-oota"><span class="secno">5.1. </span><span class="content">Using Annotations to Prevent OOTA</span><a class="self-link" href="#preventing-oota"></a></h3>
   <p>The fact that "placed before" prevents OOTA cycles simply falls out of the existing definition of "happens before", assuming the changes proposed in <a href="#fine-grained">§4 Fine-Grained Thread-Local Ordering</a> are made.  For example, the following new note, derived from Section 32.4 paragraph 9, might be added:</p>
   <blockquote>
     [ Note: For example, with x and y initially zero, 
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>acquire</c-></span><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>acquire</c-></span><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
    <p><span class="deleted">should</span> <span class="added">will</span> not produce r1 == r2 == 42, since the store of 42 to y is <span class="deleted">only possible if the store to x stores 42, which circularly depends on the store to y storing 42.</span> <span class="added">inter-thread-placed before the store of 42 to x, which is turn inter-thread-placed before the store of 42 to y, and that would form a forbidden "happens before" cycle.</span> —end note ]</p>
   </blockquote>
   <h3 class="heading settled" data-level="5.2" id="ub"><span class="secno">5.2. </span><span class="content">Cycles of Unenforced Dependencies Result in Loads Returning Unspecified Values</span><a class="self-link" href="#ub"></a></h3>
   <p>If A carries a dependency to B, but A is <i>not</i> placed before B, then orderings derived the dependency that is supposedly being carried may not in fact be enforced by the implementation.  To describe this, we introduce a notion of "unenforced dependency" as follows:</p>
   <blockquote> <span class="added"> An evaluation A <i>carries-an-unenforced-dependency</i> to an evaluation B if A carries a dependency to B, and A is not placed before B </span> </blockquote>
   <p>As discussed in, e.g., <a data-link-type="biblio" href="#biblio-p0190r3">[p0190r3]</a> and <a data-link-type="biblio" href="#biblio-p0462r1">[p0462r1]</a>, the precise definition of "carries a dependency to" is still being debated.
To the best of our knowledge so far, any variant of "carries a dependency to" that properly captures the set of behaviors prone to OOTA will suffice for our proposal.
For the moment, we simply stick with "carries a dependency to" as it is currently defined.</p>
   <p>We then build a variant of "dependency-ordered before" specifically for unenforced dependencies.  We define it by again duplicating the definition of "dependency-ordered before" from Section 6.8.2.1 paragraph 9 and then replacing "carries a dependency" with "carries an unenforced dependency".</p>
   <blockquote>
     An evaluation A is <span class="added">unenforced-</span>dependency-ordered before an evaluation B if 
    <ul>
     <li data-md>
      <p>A performs a release operation on an atomic object M, and, in another thread, B <span class="deleted">performs a consume operation on M and</span> reads a value written by any side effect in the release sequence headed by A, or</p>
     <li data-md>
      <p>for some evaluation X, A is <span class="added">unenforced-</span>dependency-ordered before X and X carries <span class="deleted">a</span> <span class="added">an unenforced</span> dependency to B.</p>
    </ul>
   </blockquote>
   <p>A cycle of "unenforced-dependency-ordered-before" represents an execution with possible out-of-thin-air behavior.  For this reason, and because "unenforced-dependency-ordered-before" is not used elsewhere, we also define it to be transitively closed.</p>
   <blockquote>
    <ul>
     <li data-md>
      <p><span class="added">for some evaluation X, A is unenforced-dependency-ordered before X and X is unenforced-dependency-ordered before B.</span></p>
    </ul>
    <p>[ Note: The relation "is <span class="added">unenforced-</span>dependency-ordered before" is analogous to "synchronizes with", but <span class="deleted">uses release/consume</span> <span class="added">release paired with unenforced-dependency-ordered-before</span> in place of release/acquire. —end note ]</p>
   </blockquote>
   <p>Because the possiblity of out-of-thin-air behavior makes the load return values unpredictable, an execution with an "unenforced-dependency-ordered-before" cycle is declared to result in loads returning unspecified values.
We acheive this by modifying Section 32.4 paragraph 9:</p>
   <blockquote>
     <span class="added">In an execution where a load A is unenforced-dependency-ordered-before itself, the value returned by the load is unspecified.</span> <span class="deleted">Implementations should ensure</span> <span class="added">In such scenarios, the implementation may not ensure</span> that no "out-of-thin-air" values are computed that circularly depend on their own computation.
[ Note: For example, with x and y initially zero, 
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
    <p><span class="deleted">should not</span> <span class="added">may</span> produce r1 == r2 == 42, since the store of 42 to y is <span class="deleted">only</span> possible if the store to x stores 42, which circularly depends on the store to y storing 42<span class="added">, and the implementation cannot in general guarantee that such unexpected behavior will not occur</span>. <span class="deleted">Note that without this restriction, such an execution is possible.</span> <span class="added">This outcome can be prevented by using stronger synchronization that ensures that the load in each thread is placed before the store in the same thread.</span> —end note ]</p>
   </blockquote>
   <h3 class="heading settled" data-level="5.3" id="ofpb"><span class="secno">5.3. </span><span class="content">The "OOTA-Free-for-Placed-Before" Theorem</span><a class="self-link" href="#ofpb"></a></h3>
   <p>Determining whether a program is prone to OOTA is likely still to be somewhere between difficult and impossible, in much the same way that statically determining the presence or absence of data races and implementing <code class="highlight"><c- n>memory_order_consume</c-></code> properly are both somewhere between difficult and impossible.  However, there is a simple and straightforward recipe that can be followed in all but the most carefully optimized cases:</p>
   <blockquote> <span class="added">A program that ensures every atomic load is "placed before" every atomic store that it is also sequenced before will not admit any executions with out-of-thin-air behavior.</span> </blockquote>
   <p>The proof is straightforward: if there are no situations where a load carries-an-unenforced-dependency to a later store, then the OOTA scenario now declared to cause loads to return unspecified values will never occur.</p>
   <p>The critierion of the theorem above can be satisfied in any number of ways, but the most straightforward solution is simply to always use <code class="highlight"><c- n>memory_order_load_store</c-></code> or stronger.
This also corresponds to reasoning described in numerous previous OOTA discussions that had proposed, e.g., to globally enforce atomic-load-to-atomic-store order.
Another solution for programmers to ensure (manually, with the burden on them to get it right) that the value returned by a <code class="highlight"><c- n>memory_order_relaxed</c-></code> load never escapes the local scope.  This may be used by expert programmers writing carefully hand-optimized data structures, such as those surveyed in <a data-link-type="biblio" href="#biblio-rats">[RAts]</a> or elsewhere.</p>
   <h2 class="heading settled" data-level="6" id="consequences"><span class="secno">6. </span><span class="content">Consequences for Existing Code</span><a class="self-link" href="#consequences"></a></h2>
   <p>Programs that pair <code class="highlight"><c- n>memory_order_release</c-></code> with forms of "placed before" other than <code class="highlight"><c- n>memory_order_consume</c-></code> and <code class="highlight"><c- n>memory_order_acquire</c-></code> will become more constrained, and certain outcomes that are currently permitted would now be forbidden.
This is true even though not all of these examples are prone to OOTA behavior.
For one example, see the load buffering example with <code class="highlight"><c- n>memory_order_release</c-></code> stores in <a href="#lb">§7.1 Load Buffering</a>.
We expect that by construction of "placed before", this strengthening is sound with respect to current hardware.</p>
   <p>This proposal also declares some unknown number of existing programs with well-defined semantics to suddenly contain loads that return unspecified values.
Programs with "unenforced-dependency-ordered before" cycles are well-defined and OOTA-free under the existing specification, but only because the specification makes a promise that implementations cannot currently keep.
As such, in spite of the current specification, these programs are already prone to OOTA behavior in practice.
The changes described in this proposal simply update the specification to better reflect this reality.
Nevertheless, pragmatically speaking, most such programs will continue to behave just as well under our proposal as they currently do under the existing specification.</p>
   <h2 class="heading settled" data-level="7" id="examples"><span class="secno">7. </span><span class="content">Examples</span><a class="self-link" href="#examples"></a></h2>
   <h3 class="heading settled" data-level="7.1" id="lb"><span class="secno">7.1. </span><span class="content">Load Buffering</span><a class="self-link" href="#lb"></a></h3>
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
   <p>This program admits an execution in which each load is "unenforced-dependency-ordered before" itself.  Therefore, the loads are considered to return unspecified values, possibly including 42.  r1 == r2 == 42 or any other possible outcome is therefore possible.
In the vast majority of cases, the implementation will actually continue to "do the right thing" here, since OOTA is generally accepted as unlikely to occur in practice.
However, if an implementation were to produce r1 == r2 == 42 in this case, e.g., due to some aggressive compiler optimization, it would now be within its rights to do so.
The burden is placed on the programmer to avoid such a scenario.</p>
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>acquire</c-></span><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>acquire</c-></span><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
   <p>The acquire annotations here break the "unenforced-dependency-ordered before" cycle.
Therefore, this program has well-defined behavior, and OOTA will be prevented.
Notably, the acquire operations have semantic meaning here even though they are not paired with release operations.</p>
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>load_store</c-></span><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>load_store</c-></span><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
</pre>
   <p>This example, which uses <code class="highlight"><c- n>memory_order_load_store</c-></code> rather than <code class="highlight"><c- n>memory_order_acquire</c-></code>, provides the same OOTA-free guarantee but using a cheaper and faster mechanism.</p>
<pre class="highlight"><c- c1>// Thread 1:</c->
<c- n>r1</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r1</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>release</c-></span><c- p>);</c->
<c- c1>// Thread 2:</c->
<c- n>r2</c-> <c- o>=</c-> <c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r2</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>release</c-></span><c- p>);</c->
</pre>
   <p>For similar reasoning, this program has well-defined behavior and will not produce OOTA behavior.
The release operations have semantic meaning even though they are not paired with acquire operations.</p>
   <h3 class="heading settled" data-level="7.2" id="histogram"><span class="secno">7.2. </span><span class="content">Histogram</span><a class="self-link" href="#histogram"></a></h3>
<pre class="highlight"><c- b>void</c-> <c- nf>histogram</c-><c- p>(</c-><c- n>std</c-><c- o>::</c-><c- n>atomic</c-><int> <c- n>buckets</c-><c- p>[</c-><c- n>B</c-><c- p>],</c-> <c- b>int</c-> <c- n>data</c-><c- p>[</c-><c- n>N</c-><c- p>])</c-> <c- p>{</c->
    <c- k>for</c-> <c- p>(</c-><c- b>int</c-> <c- n>i</c-> <c- o>=</c-> <c- mi>0</c-><c- p>;</c-> <c- n>i</c-> <c- o>=</c-> <c- n>N</c-><c- p>;</c-> <c- n>i</c-><c- o>++</c-><c- p>)</c-> <c- p>{</c->
        <c- b>int</c-> <c- n>b</c-> <c- o>=</c-> <c- n>bucket</c-><c- p>(</c-><c- n>data</c-><c- p>[</c-><c- n>i</c-><c- p>]);</c->
        <c- n>buckets</c-><c- p>[</c-><c- n>b</c-><c- p>].</c-><c- n>fetch_add</c-><c- p>(</c-><c- mi>1</c-><c- p>,</c-> <c- n>memory_order_relaxed</c-><c- p>);</c->
    <c- p>}</c->
<c- p>}</c->
</int></pre>
   <p>In this example, the use of <code class="highlight"><c- n>memory_order_relaxed</c-></code> is safe, because the return values are not used and hence cannot propagate further as unenforced dependencies.</p>
   <h3 class="heading settled" data-level="7.3" id="rfub"><span class="secno">7.3. </span><span class="content">"Reads-from-untaken-branch"</span><a class="self-link" href="#rfub"></a></h3>
<pre class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-><int> <c- n>x</c-><c- p>(</c-><c- mi>0</c-><c- p>),</c-> <c- n>y</c-><c- p>(</c-><c- mi>0</c-><c- p>);</c->

<c- c1>// Thread 1:</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>),</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->

<c- c1>// Thread 2:</c->
<c- b>bool</c-> <c- n>rfub_occurred</c-><c- p>;</c->
<c- b>int</c-> <c- n>r</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>if</c-> <c- p>(</c-><c- n>r</c-> <c- o>==</c-> <c- mi>42</c-><c- p>)</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> true<c- p>;</c->
<c- p>}</c-> <c- k>else</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> false<c- p>;</c->
  <c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c->
<c- p>}</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>return</c-> <c- n>rfub_occurred</c-><c- p>;</c->
</int></pre>
   <p>This example of "reads-from-untaken-branch" (RFUB), a variant of OOTA, is due to Hans Boehm.
In a nutshell, the compiler might detect that <code class="highlight"><c- n>r</c-></code> is always 42 in thread 2, constant-propagate the value 42 to the store to x, and then (becuase there is no annotation or carried dependency preventing it) reorder the store to x before the load of y.
This scenario admits the execution in which <code class="highlight"><c- n>rfub_occurred</c-> <c- o>==</c-> true</code>.
However, the same reasoning would fail if the <code class="highlight"><c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c-></code> statement were removed from the <i>untaken</i> branch, because the compiler would no longer be able to perform the constant propagation.
The fact that statements in an untaken branch might influence the set of legal executions is considered unexpected at best.</p>
   <p>Under our proposal, the loads in the RFUB example above would be considered to return unspecified values due to the "unenforced-dependency-ordered before" cycle.
In spite of the apparent syntactic dependency from the load in each thread to the store in the same thread, neither dependency is <i>enforced</i>, and hence neither provides any memory ordering guarantee.
Because there is an "unenforced-dependency-ordered before" cycle, the two loads are considered to return unspecified values, and hence the Thread 2 load may well return the value <code class="highlight"><c- mi>42</c-></code> that causes <code class="highlight"><c- n>rfub_occurred</c-> <c- o>==</c-> true</code>.</p>
<pre class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-><int> <c- n>x</c-><c- p>(</c-><c- mi>0</c-><c- p>),</c-> <c- n>y</c-><c- p>(</c-><c- mi>0</c-><c- p>);</c->

<c- c1>// Thread 1:</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>loadstore</c-></span><c- p>),</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->

<c- c1>// Thread 2:</c->
<c- b>bool</c-> <c- n>rfub_occurred</c-><c- p>;</c->
<c- b>int</c-> <c- n>r</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>if</c-> <c- p>(</c-><c- n>r</c-> <c- o>==</c-> <c- mi>42</c-><c- p>)</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> true<c- p>;</c->
<c- p>}</c-> <c- k>else</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> false<c- p>;</c->
  <c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c->
<c- p>}</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>return</c-> <c- n>rfub_occurred</c-><c- p>;</c->
</int></pre>
   <p>This variant of the previous example uses a <code class="highlight"><c- n>memory_order_loadstore</c-></code> annotation to ensure that thread 1 maintains proper dependency ordering.
In this scenario, there is no longer a "unenforced-dependency-ordered before" cycle, and hence the loads return well-specified values.
Nevertheless, it remains possible for both loads to return the value 42: the store in Thread 2 may still be reordered before the load, as the Thread 2 dependency is still not enforced.</p>
   <p>To analyze this example further, we propose the following interpretation:</p>
   <ul>
    <li data-md>
     <p>Old intuition: the implementation reordered the memory operations in Thread 2 because of the <code class="highlight"><c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c-></code> statement in the untaken branch</p>
    <li data-md>
     <p>New intuition: the implementation reordered the memory operations in Thread 2 because the dependency was unenforced (i.e., because the two memory operations were not related by "placed before"), and the implementation was therefore within its rights to do so</p>
   </ul>
   <p>In other words, the implementation is free (from a memory model perspective) to reorder the Thread 2 load after the Thread 2 store regardless of whether the <code class="highlight"><c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c-></code> statement is present.
The fact that it is unlikely to do so if the statement is removed becomes an implementation detail irrelevant to the actual formal analysis.
Under this interpretation, the example might even be more aptly named "reads from unenforced dependency".</p>
   <p>Even with the interpretation above, this RFUB example is likely to remain controversial, as the outcome <code class="highlight"><c- n>rfub_occurred</c-> <c- o>==</c-> true</code> is permitted even though it would never occur under a sequentially consistent execution.
We look forward to further discussion on this example.</p>
<pre class="highlight"><c- n>std</c-><c- o>::</c-><c- n>atomic</c-><int> <c- n>x</c-><c- p>(</c-><c- mi>0</c-><c- p>),</c-> <c- n>y</c-><c- p>(</c-><c- mi>0</c-><c- p>);</c->

<c- c1>// Thread 1:</c->
<c- n>y</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>x</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>loadstore</c-></span><c- p>),</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->

<c- c1>// Thread 2:</c->
<c- b>bool</c-> <c- n>rfub_occurred</c-><c- p>;</c->
<c- b>int</c-> <c- n>r</c-> <c- o>=</c-> <c- n>y</c-><c- p>.</c-><c- n>load</c-><c- p>(</c-><c- n>memory_order</c-><c- o>::</c-><span class="deleted"><c- n>relaxed</c-></span> <span class="added"><c- n>loadstore</c-></span><c- p>);</c->
<c- k>if</c-> <c- p>(</c-><c- n>r</c-> <c- o>==</c-> <c- mi>42</c-><c- p>)</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> true<c- p>;</c->
<c- p>}</c-> <c- k>else</c-> <c- p>{</c->
  <c- n>rfub_occurred</c-> <c- o>=</c-> false<c- p>;</c->
  <c- n>r</c-> <c- o>=</c-> <c- mi>42</c-><c- p>;</c->
<c- p>}</c->
<c- n>x</c-><c- p>.</c-><c- n>store</c-><c- p>(</c-><c- n>r</c-><c- p>,</c-> <c- n>memory_order</c-><c- o>::</c-><c- n>relaxed</c-><c- p>);</c->
<c- k>return</c-> <c- n>rfub_occurred</c-><c- p>;</c->
</int></pre>
   <p>This correction of the RFUB example uses <code class="highlight"><c- n>memory_order_loadstore</c-></code> annotations to ensure that the load-store reordering in question will not occur, and hence that neither OOTA nor RFUB behavior will be introduced.
The outcome <code class="highlight"><c- n>rfub_occurred</c-> <c- o>==</c-> true</code> will not occur in this scenario.</p>
   <h2 class="heading settled" data-level="8" id="future"><span class="secno">8. </span><span class="content">Future work</span><a class="self-link" href="#future"></a></h2>
   <ul>
    <li data-md>
     <p>To the best of our knowledge, our proposed changes are compatible with changes suggested by other proposals, including <a data-link-type="biblio" href="#biblio-p0668r4">[p0668r4]</a> and <a data-link-type="biblio" href="#biblio-p0735r0">[p0735r0]</a>.</p>
    <li data-md>
     <p>Is "carries a dependency to", or some proposed variant thereof, actually the right notion to use as the basis for "carries an unenforced dependency"?</p>
    <li data-md>
     <p>Should "unenforced-dependency-ordered before" cycles result in full-blown undefined behavior?  Or should they simply result in the loads in such a cycle returning unspecified values as we currently propose?</p>
    <li data-md>
     <p>What further refinement, if any, is needed to account for the counterintuitive RFUB examples?</p>
    <li data-md>
     <p>Refine any other wording and/or technical details as necessary, and fix anything I might have messed up</p>
   </ul>
   <h2 class="heading settled" data-level="9" id="ack"><span class="secno">9. </span><span class="content">Acknowledgements</span><a class="self-link" href="#ack"></a></h2>
   <p>Hans Boehm, Brian Demsky, Olivier Giroux, Paul McKenney provided valuable discussion.
This proposal more broadly also builds off of a ton of previous work by many people on dependency ordering, out-of-thin-air, and C++ memory model work in general.</p>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-ghosts">[GHOSTS]
   <dd>Hans-J. Boehm; Brian Demsky. <a href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42967.pdf">Outlawing Ghosts: Avoiding Out-of-Thin-Air Results</a>. June 13, 2014. URL: <a href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42967.pdf">https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42967.pdf</a>
   <dt id="biblio-n3710">[N3710]
   <dd>H. Boehm, et al.. <a href="https://wg21.link/n3710">Specifying the absence of "out of thin air" results (LWG2265)</a>. URL: <a href="https://wg21.link/n3710">https://wg21.link/n3710</a>
   <dt id="biblio-n4750">[N4750]
   <dd>Richard Smith. <a href="https://wg21.link/n4750">Working Draft, Standard for Programming Language C++</a>. 7 May 2018. URL: <a href="https://wg21.link/n4750">https://wg21.link/n4750</a>
   <dt id="biblio-p0098r1">[P0098R1]
   <dd>Paul E. McKenney, Torvald Riegel, Jeff Preshing, Hans Boehm, Clark Nelson, Olivier Giroux, Lawrence Crowl. <a href="https://wg21.link/p0098r1">Towards Implementation and Use of memory order consume</a>. 4 January 2016. URL: <a href="https://wg21.link/p0098r1">https://wg21.link/p0098r1</a>
   <dt id="biblio-p0190r3">[P0190R3]
   <dd>Paul E. McKenney, Michael Wong, Hans Boehm, Jens Maurer, Jeffrey Yasskin, JF Bastien. <a href="https://wg21.link/p0190r3">Proposal for New memory order consume Definition</a>. 5 February 2017. URL: <a href="https://wg21.link/p0190r3">https://wg21.link/p0190r3</a>
   <dt id="biblio-p0462r1">[P0462R1]
   <dd>Paul E. McKenney, Torvald Riegel, Jeff Preshing, Hans Boehm, Clark Nelson, Olivier Giroux, Lawrence Crowl, JF Bastien, Micheal Wong. <a href="https://wg21.link/p0462r1">Marking memory order consume Dependency Chains</a>. 5 February 2017. URL: <a href="https://wg21.link/p0462r1">https://wg21.link/p0462r1</a>
   <dt id="biblio-p0668r4">[P0668R4]
   <dd>Hans-J. Boehm, Olivier Giroux, Viktor Vafeiades. <a href="https://wg21.link/p0668r4">Revising the C++ memory model</a>. 24 June 2018. URL: <a href="https://wg21.link/p0668r4">https://wg21.link/p0668r4</a>
   <dt id="biblio-p0735r0">[P0735R0]
   <dd>Will Deacon. <a href="https://wg21.link/p0735r0">Interaction of memory_order_consume with release sequences</a>. 2 October 2017. URL: <a href="https://wg21.link/p0735r0">https://wg21.link/p0735r0</a>
   <dt id="biblio-p0750r1">[P0750R1]
   <dd>JF Bastien, Paul E. McKenney. <a href="https://wg21.link/p0750r1">Consume</a>. 11 February 2018. URL: <a href="https://wg21.link/p0750r1">https://wg21.link/p0750r1</a>
   <dt id="biblio-rats">[RAts]
   <dd>Matthew D. Sinclair; Johnathan Alsop; Sarita V. Adve. <a href="http://rsim.cs.illinois.edu/Pubs/17-ISCA-RAts.pdf">Chasing Away RAts: Semantics and Evaluation for Relaxed Atomics on Heterogeneous Systems</a>. June 24, 2018. URL: <a href="http://rsim.cs.illinois.edu/Pubs/17-ISCA-RAts.pdf">http://rsim.cs.illinois.edu/Pubs/17-ISCA-RAts.pdf</a>
   <dt id="biblio-webkit">[WebKit]
   <dd>JF Bastien; Filip Jerzy Pizło. <a href="https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Atomics.h?rev=+217722#L342">WebKit source: WTF Atomics.h</a>. June 2, 2017. URL: <a href="https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Atomics.h?rev=+217722#L342">https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Atomics.h?rev=+217722#L342</a>
  </dl>