Repository navigation
Conversation
…o THAT processor, by identity — not a false theorem charging another processor's thread (#498) threads_for_processor compared the last segment of each thread's binding with the processor's NAME. Two different processors that share a name (`left.cpu` and `right.cpu`, both `cpu`) each collected both threads. On the published v0.46.0 binary, `spar codegen --verify proof` on that model emits a scheduling theorem that charges `t` 6 ms of interference from a thread running on the OTHER processor: 6 + 6 = 12 ms against a 10 ms deadline, which is a false theorem. With one processor per node named both `cpu` and `left.cpu`, each proof collected all four threads instead of its two. The binding now resolves from the component that declared it (actual_processor_binding_with_overlay, REQ-AADL-REF-CONTEXT-001) and is compared by identity. An unresolved binding keeps the old name comparison. Oracles: - CLI tests on the generated Lean: one theorem with no foreign interference; two theorems where a processor really has two threads (both red on v0.46.0); - unit test: each same-named processor gets exactly its own thread, by instance path. cargo-mutants found that `bound == proc_idx` flipped to `!=` SURVIVED the CLI tests: both threads are `t` and #510's file collision hides which proof survives. It is caught by this test; - cargo-mutants (spar-codegen, spar): 1 caught, 1 unviable, plus that survivor, now caught. Found while writing this: both processors also write proofs/cpu_scheduling.lean, so one proof overwrites the other (#510). Refs #498, #510 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnBWxgVEUPdsBTLNKtrA6Z
Rivet verification gate✅ 20/20 passed
Filter: Failed artifacts(none) Updated automatically by |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
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.
threads_for_processor compared the last segment of each thread's binding
with the processor's NAME. Two different processors that share a name
(
left.cpuandright.cpu, bothcpu) each collected both threads. Onthe published v0.46.0 binary,
spar codegen --verify proofon thatmodel emits a scheduling theorem that charges
t6 ms of interferencefrom a thread running on the OTHER processor: 6 + 6 = 12 ms against a
10 ms deadline, which is a false theorem. With one processor per node
named both
cpuandleft.cpu, each proof collected all four threadsinstead of its two.
The binding now resolves from the component that declared it
(actual_processor_binding_with_overlay, REQ-AADL-REF-CONTEXT-001) and is
compared by identity. An unresolved binding keeps the old name
comparison.
Oracles:
interference; two theorems where a processor really has two threads
(both red on v0.46.0);
instance path. cargo-mutants found that
bound == proc_idxflipped to!=SURVIVED the CLI tests: both threads aretand codegen --verify proof names each processor's Lean proof by the processor's NAME — two processors named cpu write one file, the second silently overwrites the first #510's filecollision hides which proof survives. It is caught by this test;
survivor, now caught.
Found while writing this: both processors also write
proofs/cpu_scheduling.lean, so one proof overwrites the other (#510).
Refs #498, #510
🤖 Generated with Claude Code
https://claude.ai/code/session_01BnBWxgVEUPdsBTLNKtrA6Z