[cpp-threads] Review of N2995 and resulting email threads

[Paul E. McKenney]

Hello!

It was suggested that I review N2995 and the related email threads and
comment appropriately.

This paper contains suggested changes to the C++ memory model in clause
1.10 and 29.3.  Following are my suggested -technical- dispositions.
I make no recommendation as to timing or optimal procedural handling of
these technical dispositions.  That said, all of the suggested changes
to 29.3 have already been processed via Lawrence's paper, and all of
the proposed changes to 1.10 are either clearly editorial in nature or
are to non-normative text.  ;-)

I would be happy to discuss tomorrow (Saturday) morning at Core, as was
also suggested.

Thoughts?

							Thanx, Paul

------------------------------------------------------------------------

Suggested disposition of the suggestions in N2955:

o	1.10p2: replace "might be" with "is".
	
	--- Editorial

o	1.10p4: Add note:

	[Note: Atomic and locking objects are not trivially
	copyable [3.9], so executions that access atomic
	or locking objects as non-atomic objects, for example
	through an array of character type, will have undefined
	behaviour - end note]

	--- I believe that this is straightforward enough to qualify
	--- as editorial.

o	1.10p6: replace "M is a maximal contiguous" with
	"M is a maximal-length contiguous".

	--- Editorial

o	1.10p12: Instead of adding the "if one exists" wording,
	suggest instead stating that A can be initialization.

	[Note: For the purposes of this paragraph, the initial
	value of M can take on the role of a visible side effect
	A, so that the initial value of M can be the value of
	M as determined by evaluation B.]

	--- Non-normative, but deserves careful review.

o	1.10p13: Yow!!!  As with 1.10p12, I suggest a note
	explaining that the initial value of a variable can,
	for the purposes of this paragraph, be considered a
	"beginning of time" side effect.  Hans also suggests
	this in his September 21 reply to Mark Batty.

	[Note: For the purposes of this paragraph, the initial
	value of M can take on the role of a visible side effect,
	so that the initial value of M can be the value of M as
	determined by evaluations A and B.]

	--- Non-normative, but deserves careful review.

o	1.10p14: Use of casts or unions can result in atomic and
	non-atomic accesses to the same memory location, so the "at least
	one of which is not atomic" must remain.  Peter Dimov pointed out
	that memcpy() can have the same effect.  Therefore, I am -not-
	OK with the suggested modifications to the first sentence --
	if any of the accesses are non-atomic, there can be a data race.
	It is not necessary for -all- of them to be non-atomic.

	However, I -am- OK with the addition of "and atomic memory order
	seq cst operations" so that first sentence of the note reads:

	"Note: It can be shown that programs that correctly use
	simple locks and atomic memory_order_seq_cst operations to
	prevent all data races, and use no other synchronization
	operations, behave as though the executions of their
	constituent threads were simply interleaved, with each
	observed value of an object being the last value assigned
	in that interleaving.  This is normally referred to as
	'sequential consistency'."

	--- Non-normative, but deserves careful review.

o	29.3p8: Add prior to the note:

	The implementation shall move neither an atomic
	side effect nor an atomic value computation contained
	in a substatement of one of the selection statements
	specified in 6.4 out of the substatement.

	[Hans later recommended against this change.]

	--- Mark withdrew this suggestion.  No change.

o	29.3p9: Replace "Implementations shall not move an
	atomic operation out of an unbounded loop" with
	"The implementation shall move neither an atomic side
	effect nor an atomic value computation contained in a
	substatement of one of the iteration statements specified
	in 6.5 out of the substatement."

	[Hans later recommended simply striking this sentence.
	One of the supporting examples transforms a loop:

		for (;;) x = 17;

	to:

		x = 17; for (;;);
	
	when there are no other stores to x.  This is clearly
	permitted by the as-if rule, but the suggested text
	would prohibit this optimization.  Hence the desire to
	strike it.
	
	Peter Dimov counters by suggesting that all threads be
	optimized to "for (;;)".

	Clark Nelson notes that we already have "atomic operation"
	that covers both "atomic side effect" and "atomic value
	computation", so we should keep using "atomic operation".
	
	Mark Batty concurs with Hans, as does Peter Dimov.]

	--- Covered by Lawrence's atomics paper, no further action needed.