Remove workaround for lack of std::atomic_init

[JoeLoser]

Summary:

• Since GCC 5 and later has std::atomic_init, remove the workaround
  present in Tearable.h to default initialize atomic variables.
• Default initialization of atomics do not work as you would expect. See
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0883r0.pdf
  for the explanation why.
• To get around the default initialization issue, we just call
  std::atomic_init for each element in the array of atomics.

[facebook-github-bot]

@yfeldblum has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[yfeldblum]

From internal review, pedantically, this leaves the atomic in uninitialized state.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0883r0.pdf

So Tearable would need either this intermediate type or to call std::atomic_init in a loop.

[JoeLoser]

Thanks for the paper link; I was not aware of this gotcha. It's a bit unfortunate the default initialization for atomics is broken IMO. I like Herb's quote of

I have never seen the current behavior of deliberately failing to initialize an atomic (to the obvious default value of T{}) to be anything but a source of user surprise and a bug farm.

In any case, I decided to switch to using an array of atomics and explicitly call std::atomic_init for each element. I think this new behavior is a bit more explicit in our intent to default initialize the elements rather than through the intermediate type. What do you think?

[facebook-github-bot]

@yfeldblum has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.