]> git.lizzy.rs Git - rust.git/commit
Auto merge of #105590 - solid-rs:patch/kmc-solid/thread-lifecycle-ordering, r=m-ou-se
authorbors <bors@rust-lang.org>
Thu, 29 Dec 2022 04:22:25 +0000 (04:22 +0000)
committerbors <bors@rust-lang.org>
Thu, 29 Dec 2022 04:22:25 +0000 (04:22 +0000)
commit6ad83834515912c5e529e0e9fe326d5060d937cf
tree320238d92f74ca6918ba2dcfecac0c42b132e0eb
parentb15ca6635f752fefebfd101aa944c6167128183c
parent6fbef06f26b038c97578dfb8a577e68ec0189f37
Auto merge of #105590 - solid-rs:patch/kmc-solid/thread-lifecycle-ordering, r=m-ou-se

kmc-solid: Fix memory ordering in thread operations

Fixes two memory ordering issues in the thread state machine (`ThreadInner::lifecycle`) of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.

1. When detaching a thread that is still running (i.e., the owner updates `lifecycle` first, and the child updates it next), the first update did not synchronize-with the second update, resulting in a data race between the first update and the deallocation of `ThreadInner` by the child thread.
2. When joining on a thread, the joiner has to pass its own task ID to the joinee in order to be woken up later, but in doing so, it did not synchronize-with the read operation, creating possible sequences of execution where the joinee wakes up an incorrect or non-existent task.

Both issue are theoretical and most likely have never manifested in practice because of the stronger guarantees provided by the Arm memory model (particularly due to its barrier-based definition). Compiler optimizations could have subverted this, but the inspection of compiled code did not reveal such optimizations taking place.