Repository navigation
hansei-bundle, exegesis, hansei-runtime: read std's pthread mutex - #22
Merged
Merged
Conversation
When the assessor cannot prove a task's wait, the task block prints only the class of the reason, such as "the resource's state is not one its protocol vouches for". The assessor also records what it found -- which word did not read, which lock it could not decode -- but the block prints those notes only under a verified wait. In a core of the repository's example program (`example/`) taken on illumos, six tasks showed the class alone, and learning that all six failed on the same undecodable lock took a temporary build that printed the notes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The wait assessment trusts a semaphore's, Notify's or io registration's wait list only after it checks that the list's lock was not held when the core was taken, and it can decode only parking_lot's raw mutex and std's futex mutex. A tokio built without its `parking_lot` feature guards those lists with std's mutex, which on illumos is the pthread mutex, so every such wait is unknown: six of the ten tasks in a core of `example/`. std's pthread mutex keeps its `pthread_mutex_t` in a heap block it allocates on first lock, so a lock word can now live in a block the lock points to. A null pointer reads as unlocked. The word is illumos libc's lock byte, which std's sources don't determine, so the binding requires the libc crate's solarish `pthread_mutex_t`; any other platform's declines. With this change, all six tasks in that core show their waits. No fixture core waits behind a pthread mutex, since the fixtures' tokio uses parking_lot, so the runtime side is otherwise tested only on constructed bytes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The wait assessment trusts a semaphore's, Notify's or io registration's wait list only after it checks that the list's lock was not held when the core was taken, and it can decode only parking_lot's raw mutex and std's futex mutex. A tokio built without its
parking_lotfeatureguards those lists with std's mutex, which on illumos is the pthread mutex, so every such wait is unknown: six of the ten tasks in a core of
example/.std's pthread mutex keeps its
pthread_mutex_tin a heap block it allocates on first lock, so a lock word can now live in a block the lock points to. A null pointer reads as unlocked. The word is illumos libc's lock byte, which std's sources don't determine, so the binding requires the libc crate's solarishpthread_mutex_t; any other platform's declines.With this change, all six tasks in that core show their waits. No fixture core waits behind a pthread mutex, since the fixtures' tokio uses parking_lot, so the runtime side is otherwise tested only on constructed bytes.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com