[libcxx-commits] [PATCH] D68480: Implementation of C++20's P1135R6 for libcxx

[Olivier Giroux via Phabricator via libcxx-commits]

__simt__ marked 3 inline comments as done.
__simt__ added a comment.

In D68480#1705203 <https://reviews.llvm.org/D68480#1705203>, @EricWF wrote:

> Are the lock free algorithms used by this implementation published somewhere? That would give me a lot more confidence in their correctness.


Now that's getting to the meat of the matter! The short answer is no, and the long answer is that it depends on what we're going to call an algorithm.

The <latch> code is more-or-less the spec's exposition converted into code, but I think it needs to become more complex later, for QoI reasons. In <barrier> we have well-known barrier algorithms <https://6xq.net/barrier-intro/> like linear/central and tree/hierarchical barriers, but the pseudocode you'll find in literature needs a lot of adaption to fit into C++ in general (which doesn't do thread-local non-static members for classes), and into the C++20 std::barrier interface in particular (which doesn't assign a dense index space of IDs to thread that could be used to access O(P)-sized internal structures) -- and all that adaptation is 90% of the code in that file, not the algorithm itself. Finally, the gnarly code in <semaphore> is not the semaphore algorithm proper either (because that's been left to the OS except for the fallback cases) but the acceleration layer that one would need to put on top of it in order to make it fast (avoid calling the OS when it's not strictly necessary).

To be clear, I am reasonably concerned that there are bugs in this code, as well. The simpler / lower-QoI paths which CUDA will eventually ship are decently solid, but the complex / high-QoI paths that a performant CPU implementation needs (read: existentially needs, even in ~6 core laptop) are not as well tested relative to their complexity.

On our end, I think our intentions are to write more fuzzer-like tests that apply stress on them. I also have in the back of my mind the idea of proposing a C++Now talk in the vein of "How-to P1135 <https://reviews.llvm.org/P1135> @ High QoI", to capture more eyeballs / document the post-adaptation versions of the algorithms better.

Where would you like to take this chat next?


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68480/new/

https://reviews.llvm.org/D68480