DIP 1024---Shared Atomics---Community Review Round 2

[Manu]

On Sun, Oct 27, 2019 at 2:25 PM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 27.10.19 13:20, Mike Parker wrote:
> > This is the feedback thread for the second round of Community Review for
> > DIP 1024, "Shared Atomics":
> >
> > https://github.com/dlang/DIPs/blob/0093abce72fa803b9e4067db500171c634daa4a9/DIPs/DIP1024.md
> >
> >
> > All review-related feedback on and discussion of the DIP should occur in
> > this thread. The review period will end at 11:59 PM ET on November 10,
> > or when I make a post declaring it complete.
> >
> > At the end of Round 2, if further review is deemed necessary, the DIP
> > will be scheduled for another round of Community Review. Otherwise, it
> > will be queued for the Final Review and Formal Assessment.
> >
> > Anyone intending to post feedback in this thread is expected to be
> > familiar with the reviewer guidelines:
> >
> > https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> >
> > *Please stay on topic!*
> >
> > Thanks in advance to all who participate.
>
> Looks good, except for this sentence:
>
> "Atomic reads perform an acquire operation, writes perform a release
> operation, and read-modify-write performs an acquire, then a
> modification, and then a release. The result is sequentially consistent
> ordering, and each thread observes the same order of operations (total
> order)."
>
> While atomics that act like this already provide some useful guarantees,
> this is not enough to ensure sequential consistency for more than two
> threads. This post explains it well: https://stackoverflow.com/a/14864466
>
> Probably the sentence can just be dropped from the DIP, as it does not
> actually describe a language change, and core.atomic is more general
> than this anyway.

I had this thought too.
The atomic functions all accept arguments which define the fence
strategies anyway. The rules stated are not strictly necessary, or
actually true.