<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Dec 14, 2018 at 12:32 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:<br></div><div dir="ltr"><br></div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It was *one of* the understood implementation strategies. Another was specific HW support, and yet another was the compiler just always “doing the right thing” w.r.t. padding (which is the approach you seem to want to take).</blockquote><div><br></div><div>The approach I'm in favor of is not a viable strategy for implementing the paper's changes, because it'd violate the new requirement that padding must be ignored. Rather, I believe that if the implementation "does the right thing" with padding, the need to make the standards change in the first place is greatly reduced. Where by "does the right thing", I mean "does what C specifies": padding bits may mutate in any arbitrary way upon a write to a field in an object, (including via struct copy), but cannot just change out of the blue.</div><div><br></div><div>In that world, a compare_exchange_strong on a struct with padding can fail the first time it's invoked (which would violate the new spec), but can be guaranteed to succeed the second loop iteration as long as you pass back the same "expected" pointer. If users could rely on this behavior, I think it would be sufficient to simply note "Watch out for padding if you do a compare_exchange operation without a loop around it" -- which is effectively what the spec said pre-c++20.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div>Had it been discussed that the example in the R0 paper was not an infinite-loop because padding is unspecified during object initialization object copies, as the paper suggests is the case?</div></div></div></div></blockquote><div><br></div><div>?</div></div></div></blockquote><div><br></div><div>The paper gives the impression that the problem it is addressing is that padding bits are unpredictable when copying or initializing an object -- e.g. that the padding bits in "desired" may be mutated because it's being passed by value. Both sections 1.1 and the example program in Section 3 -- especially the comments indicating "Padding bits added and removed here" and "Maybe changed here as well" -- strongly imply that.</div><div><br></div><div>However, that is not the major issue -- the contents of padding in the atomic's object's current state, or in the initial value of "expected" before entering the loop, or in any copy of "desired" will only cause a single extra iteration of the loop rather than infinite extra iterations.</div><div><br></div><div>Major problems occur only if "expected" can change its memory representation between being written to as-if by memcpy via the compare_exchange_strong in the first iteration of the loop, and then being compared against as-if by memcmp via the compare_exchange_strong in the second iteration of the loop -- where there are no intervening write operations occurring on it.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div>But, that there is a potential infinite loop only if the C++ standard allows the padding bits in "expected" to arbitrarily modify themselves at any time between the iterations of the loop, which, unfortunately, it would appear to allow?</div></div></div></div></blockquote><div>This is exactly what the paper is addressing, yes.</div></div></div></blockquote><div><br></div><div>OK. It was not clear from the paper itself that it was intending to address this issue, rather than the other.</div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div>