GeezerVison

TSAN complains about data races between the non-atomic load of `tstate->state` in
`detach_thread()` and `tstate_set_detached()` and the atomic compare/exchange of
`tstate->tstate` in `park_detached_threads()`. I believe this is due to a bug with
how TSAN models compare/exchange (treating it solely as a store, rather than a load/store).

According to the standard,

> If one evaluation modifies a memory location, and the other
> reads or modifies the same memory location, and if at least one
> of the evaluations is not an atomic operation, the behavior of
> the program is undefined (the program has a data race) unless
> there exists a happens-before relationship between these two
> evaluations.

However, according to the standard, A happens-before B if any of the following are
true:

> 1) A is sequenced-before B.
> 2) A synchronizes-with B.
> 3) A strongly happens-before X, and X strongly happens-before B.

Using this we can establish a happens-before relationship between each non-atomic
load and the compare/exchange:

1. Each non-atomic load is sequenced-before the seq-cst store to `tstate->state` that
   happens in `tstate_set_detached()`. Therefore, each non-atomic load happens-before
   the seq-cst store.
2. The seq-cst store to `tstate->state` in `tstate_set_detached()` synchronizes-with
   the compare/exchange to `tstate->state` in `park_detached_threads()`. Thus the seq-cst
   store happens-before the compare/exchange.
3. (1) and (2) establish the happens-before relationship between the non-atomic load and
   the compare/exchange on `tstate->state`, therefore it should not be flagged as a
   data race.