-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
minimal trace mode #131
Comments
We're about to need to call it earlier in header.c. Github: related to #131 "minimal trace mode"
Similarly to state_depth, we're going to need to refer to this earlier. Github: related to #131 "minimal trace mode"
In upcoming changes we'll need to read running_count within error() to determine whether we're single threaded or not. To do this while avoiding torn reads, we need to use atomic reads and writes with running_count. Github: related to #131 "minimal trace mode"
The bail out condition will soon need to ask about the state depth as well. Github: related to #131 "minimal trace mode"
This commit needs significant work and doesn't function correctly as-is. Github: related to #131 "minimal trace mode"
In some upcoming changes we need to refer to it in preprocessor guards. Github: related to #131 "minimal trace mode"
The purpose of this seemingly irrelevant change is to ensure we opt out of the rendezvous protocol as soon as error() is called when MAX_ERRORS == 1. In upcoming changes to ensure we get the shortest resulting trace, we're going to loop indefinitely in error(). This is only possible without livelocking if we're no longer part of the thread rendezvous protocol. Github: related to #131 "minimal trace mode"
Similarly to state_depth, we're going to need to refer to this earlier. Github: related to #131 "minimal trace mode"
In upcoming changes we'll need to read running_count within error() to determine whether we're single threaded or not. To do this while avoiding torn reads, we need to use atomic reads and writes with running_count. Github: related to #131 "minimal trace mode"
The bail out condition will soon need to ask about the state depth as well. Github: related to #131 "minimal trace mode"
Github: Closes #131 "minimal trace mode"
Github: related to #131 "minimal trace mode"
After some protracted debugging, I realised there's a fundamental blocker to implementing this. Because of the way multithreaded exploration works, the first time a state is encountered it is not guaranteed to be found via the shortest path. E.g. consider the following FSM:
Thread 0 might discover There are a couple of ways I can think of solving this, neither of them good:
Bottom line, both of these introduce unacceptable overhead. I think we either need a third option or give up on this feature. |
When bringing up a model, you typically want to run with max errors 1 and multithreaded but also get a minimal trace. This is not currently possible but we could implement this by not actually signaling an error until all other threads have exceeded the depth at which the error was found.
The text was updated successfully, but these errors were encountered: