- User Since
- Dec 10 2018, 1:57 PM (44 w, 3 d)
Oof, didn't attach the patch.
Added some documentation for the semaphore and barrier algorithms as comments.
Fixed an incompatibility between the _Atomic(T) backend of <atomic> and the Futex function SFINAE in <__threading_support>.
Simplified how the contention state is conditionally-used.
Refactored the semaphores into layers that each do one clear thing, and dispensed with a lot of #ifdefs. Moved as much semaphore code as possible out of the header and into the dylib.
Thu, Oct 10
Wed, Oct 9
Was missing an edit to the header CMakeLists to install the new headers.
Tue, Oct 8
Sorry for the delay posting the updated patch that addressed the recent comments, but I ran into some build issues.
I've processed a number of issues for my next patch.
Sun, Oct 6
My Mac tests didn't catch some Linux issues when I added __ almost everywhere.
Closed some of the comments that have been addressed.
This new patch has more context, more __, fewer escapes from the CUDA port.
Sat, Oct 5
Urg, sorry for struggling with UX here.
Fri, Oct 4
Cleaned up a dead macro
Removed some mentions of CUDA that slipped by
Cleaned up the patch a bit.
Jul 26 2019
I think we want people to use -ffreestanding more for things like this, so the part where this is circumvented isn't clearly the right choice. The rest seems fine, and is exactly the reason why I created _LIBCPP_ATOMIC_ONLY_USE_BUILTINS.
Jun 13 2019
Jun 11 2019
I know some things about CUDA, volatile and C++. Let's see if I can understand the part of the proposed change that involves these. I don't understand the part about the test but I don't need to, I'll ignore that.
Mar 4 2019
Mar 3 2019
Feb 25 2019
Hey guys, can I get additional feedback or else proceed with this patch?
Feb 14 2019
Dear other reviewers, what else needs to happen here?
Feb 12 2019
This version addresses the preceding comments and passes libcxx tests across c++03, 11, 14 and 17 modes.
Feb 11 2019
Would it make sense to decide whether we want to use GCC's non-lockfree atomics or not based on a configuration macro that's not _LIBCPP_FREESTANDING?
Feb 8 2019
This version passes libcxx tests with each combination of path that can be used (force GCC, force C11, force freestanding+non-lock-free). There were quite a few problems around volatile that I had not addressed yet, apologies.
Feb 7 2019
I need to test the GCC path better, it still has some bugs. Be right back.
Feb 6 2019
In this version:
Feb 5 2019
I will come back with another patch that addresses these comments.
Feb 4 2019
In this version I've restored the __cxx_atomic_... layer to which both the GCC and C11 backends map. This addresses the comment about introducing more functions named __c11_atomic... which are not part of the C11 builtin set. I do not introduce any new versions of _Atomic anymore.
Thanks for the comments, Louis, responses below.
Jan 31 2019
Removed an inadvertent #define left in there for testing.
Would be better if it passed the libcxx tests with the feature turned on. Like now.
Fixed some spurious whitespace changes I didn't intend.
Simplified the changes significantly. By switching my back-end to slide under the C11 side instead of the GCC/Clang side, I can live without the new interposer layer.
Jan 30 2019
Quick update before a longer update: I have a simpler patch on the way.
Jan 18 2019
Updated the patch with a bit higher-quality and better-tested code than what I originally showed.
With apologies, I would just like to tack a note into this thread that the entire *field* of formal memory model proofs involving partially-overlapping atomics is a single paper (last I knew, https://www.cl.cam.ac.uk/~pes20/popl17/mixed-size.pdf). The paper says mixed-size, but the key point is not-perfectly-overlapping.
Just a clarification - please evaluate the design aspects first. There are nits that I know are wrong and am still working on.