Eliza Weisman

> Although there is no bounds checking on the array, it still checks whether the entry is occupied and so there is a branch and panic handling code due to...

The tricky part here is generating a unique, durable identifier for the current test. If `cargo test` is not run with `--test-threads=1`, the current thread name should be the name...

Hmm, this certainly _looks_ off...that error _should_ only be emitted if the atomic `get_mut` method is used, which it appears your test never does. This could be a bug!

Sorry if my first comment wasn't clear! What I meant is, `loom` only emits "Causality violation" errors when an access would _violate the C++11 memory model_ — that error doesn't...

Also, looking at the code, the only place where an atomic will print the specific error message "concurrent load and mut accesses"[^1] is here: https://github.com/tokio-rs/loom/blob/6d159963a1dafe961478b549a71d1409af712485/src/rt/atomic.rs#L568-L582 which is only called inside...

Hmm, it's strange that your panic is missing a `with_mut` location, which the code in `track_load()` _should_ add to the error message. That's what's confusing me about this...

As a side note, I recently hit the same error in some code of my own. I _think_ what's happening here is that loom is (perhaps incorrectly?) treating the _creation_...

Oh, okay, I've figured something out. It looks like one of the two locations is not being printed because no location was captured for a write on that thread...which means...

I've also hit this, though I didn't have the time to put together a minimal reproduction --- thanks for that!

I did some digging, and it looks like this is because the admin thread never actually joins – when it receives the `/shutdown` endpoint, it sends the shutdown signal on...