Repository navigation
Count a livelock from its first stalled cycle - #288
Merged
Merged
Conversation
The pending signal count a stalled cycle is compared against was taken before the previous cycle's drain. When a stall began right after a productive cycle the counts differed, so the first stalled cycle was not counted and WithLivelockThreshold(n) fired one cycle late. The baseline is now taken after the drain. The error no longer says components "never activated" when they only have no input signals in the stalled cycle, and the unreachable "dropping inputs" branch is gone: in a stalled cycle every recorded result keeps its inputs. The docs no longer call detection exact. It assumes a waiter decides from its inputs alone; one that proceeds on its State, the clock or the outside world is reported as livelocked.
Benchmark report (advisory)Statistically significant changes: 17 regression(s), 11 improvement(s) (PR head vs. base branch).
Higher is worse on every metric. Full benchstat table |
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.
Before: a stall that began right after a productive cycle was reported one cycle late, after n+1 stalled cycles instead of
WithLivelockThreshold(n). The error also said components "never activated" when they had activated in earlier cycles, and the docs called detection "exact, not a guess".After: the threshold is exact. The error says
N other component(s) have no input signals. The docs state what detection assumes: a waiter decides from its inputs alone.Why
The pending signal count a stalled cycle is compared against was taken before the previous cycle's drain. When the drain changed the count, the first stalled cycle did not match it and was not counted. A waiter that proceeds because of its
State(), the clock or something outside the mesh looks stuck while it waits and gets stopped as livelocked. That is a limit of the design, so it is now documented and tested rather than claimed away.How
Runrecords the baseline count after each drain.detectLivelockcounts the pending signals only when every activated component kept its inputs.livelockErrordrops the "dropping inputs" branch, which could never run because every recorded result in a stalled cycle keeps its inputs. It also fixes the wording for components with no input.runtime.md, wiki 401 andconfig.goare updated. No CHANGELOG entry: that is written at release time.make checkpasses with golangci-lint v2.13.1. The new threshold and message tests fail on main.