Loom panics with "inconsistent park_timeout state: 1"

[notgull]

While testing loom permutations on async-lock (smol-rs/async-lock#86) I got this error:

RUST_BACKTRACE=1 RUSTFLAGS="--cfg loom" cargo test --test loom --features loom
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running tests/loom.rs (target/debug/deps/loom-70b925f2c1f2a548)

running 1 test
test barrier_smoke ... FAILED

failures:

---- barrier_smoke stdout ----
thread 'barrier_smoke' panicked at /home/jtnunley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parking-2.2.0/src/lib.rs:359:23:
inconsistent park_timeout state: 1
stack backtrace:
   0: rust_begin_unwind
             at /rustc/b1ec1bd65f89c1375d2cf2fb733a87ef390276d3/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /rustc/b1ec1bd65f89c1375d2cf2fb733a87ef390276d3/library/core/src/panicking.rs:72:14
   2: parking::Inner::park
             at /home/jtnunley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parking-2.2.0/src/lib.rs:359:23
   3: parking::Parker::park
             at /home/jtnunley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parking-2.2.0/src/lib.rs:121:9
   4: event_listener::InnerListener<T,B>::wait_with_parker
             at /home/jtnunley/.cargo/registry/src/index.crates.io-6f17d22bba15001f/event-listener-5.3.0/src/lib.rs:1139:25

...yada yada yada

Not sure why this hasn't cropped up in production yet. Possibilities:

• This bug isn't possible with the x86_64 memory model and only happens theoretically in the C memory model.
• This bug is so cosmically rare no one has reported it yet (or worse, bothered to report it).
• This is a bug in loom. (Unlikely)

[notgull]

Now that I think about it, this panic really shouldn't be happening. Only one thread should be able to call park at a time (since Parker is Send but not Sync), so there shouldn't be a window where the state value is PARKED when fn park() is started.

[notgull]

Nevermind, this was just an issue with using std::thread_local instead of loom::thread_local. Still, it might be useful to have an error message for this.