Line 422 needs to be fixed before I resign or approve this change, but I have a few comments and questions as well.

In D126669#3546172, @MaskRay wrote:

This change is fine (if I were adding the tests in the first place, I'd add -c or -S), but I'd like to understand why you have such a toolchain not supporting linking.
Such special requirements make me feel odd.

It seems like this was the correct solution this time around, since it appears we prefer clang over clang++ if we are also specifying -std=c++XX, but for future reference instead of %clang++ the correct way of invoking clang++ from a test is %clangxx

Follow up on @EricWF's comments based on a video chat with him:
Since id::__get is apparently hit quite often, the extra performance we might get here because of the relaxed memory ordering instead of acquire/release ordering could potentially be significant. Not to mention that in the happy path we replace 1 atomic load (from id::__flag_.__state_) and 1 non-atomic load (from id::__id_) with a single atomic load (from id::__id_). I do have to run some benchmarks to double check, but I would be shocked if this somehow hurt performance.
Comparing the old sequence to the new sequence side by side makes this pretty obvious I think.

In D120348#3375321, @zibi wrote:

The __libcpp_is_threading_api_enabled() checks if threading is enabled (POSIX ON) or not (POSIX OFF) as its name clearly indicates. It cannot be changed throughout the
live of the application but it can be set at the start of the application via env. var. _CEE_RUNOPTS=POSIX(OFF).

However, the __libcpp_might_have_multiple_threads() can be changed in the life of the application. It is needed so the single threading execution can be made optimum.

In D117372#3374008, @EricWF wrote:

Do we have tests that fire up a bunch of threads and construct various locale::ids concurrently? If not we should add some. That will allow TSAN to diagnose bugs.

In D120668#3349265, @arsenm wrote:

This does look similar at first glance. What's the point of doing this? Why were these paths split in the first place?

LGTM

Ping, since as per my previous comment, I'm pretty sure this change will have broken _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL.

No change, rebase so hopefully CI passes this time

As per review comment, change heading level for Compact Unwind so it's no longer under Prolog/Epilog

Not really sure who to add as a reviewer for this. Feel free to add/remove people.

In D117366#3266416, @ldionne wrote:

There's a lot of quite useful information in there. However, it's not clear to me that a "DesignDoc" is the right place to put it. I'm truly scared that this is going to get out of sync with the actual code in no time at all, especially the parts that explain the current implementation of <something>. Instead, would it make sense to improve the in-code documentation of the various parts you describe by adding those descriptions as high-level comments in the code itself, close to the implementation? Then, this design doc can stay higher level and not risk getting out of sync.

Address reveiw comments

No change. Rebase onto D117366 and re-trigger CI

@Quuxplusone I've addressed the comments you made that were easy to address. The rest will take me some time to get to as I have other items I need to work on at the moment.

Address some of @Quuxplusone's comments

Add InternalThreadSynchronization to libcxx/docs/index.rst

Update abi lists

Fix "Duplicate explicit target name" error.

Fix copy-paste error

Remove documentation update (and move to D117372, since it's more appropriate there)

Update Documentation

Update Documentation

Address review comments

Ping

Ping

In D115906#3231458, @ldionne wrote:

For the Pthread case, using _LIBCPP_THREAD_ABI_VISIBILITY and inline _LIBCPP_HIDE_FROM_ABI is equivalent.

Should this have used _LIBCPP_THREAD_ABI_VISIBILITY instead? Won't this break _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL? Also, why is this needed when the forward declarations already specify that the functions are inline?

Update because of changes to dependent revisions

Rebase and address review comments