Skip to content
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

Open
Smattr opened this issue Jun 1, 2019 · 1 comment
Open

minimal trace mode #131

Smattr opened this issue Jun 1, 2019 · 1 comment

Comments

@Smattr
Copy link
Owner

Smattr commented Jun 1, 2019

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.

Smattr added a commit that referenced this issue Jun 9, 2019
We're about to need to call it earlier in header.c.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 9, 2019
Similarly to state_depth, we're going to need to refer to this earlier.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 9, 2019
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"
Smattr added a commit that referenced this issue Jun 9, 2019
The bail out condition will soon need to ask about the state depth as well.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 9, 2019
This commit needs significant work and doesn't function correctly as-is.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 16, 2019
In some upcoming changes we need to refer to it in preprocessor guards.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 16, 2019
We were always passing the set_update function for this parameter, so just hard
code a call to this. The larger motivation for this is that we want to move the
rendezvous opt out to an earlier location in header.c. This backs out part of
8cf9d78.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 16, 2019
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"
Smattr added a commit that referenced this issue Jun 16, 2019
Similarly to state_depth, we're going to need to refer to this earlier.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 16, 2019
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"
Smattr added a commit that referenced this issue Jun 16, 2019
The bail out condition will soon need to ask about the state depth as well.

Github: related to #131 "minimal trace mode"
Smattr added a commit that referenced this issue Jun 16, 2019
Smattr added a commit that referenced this issue Jun 16, 2019
Github: related to #131 "minimal trace mode"
@Smattr
Copy link
Owner Author

Smattr commented Jun 18, 2019

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:

A -> B -> C
 \        ^
  \______/

Thread 0 might discover C first via the path A -> B -> C. Later thread 1 might rediscover C via the path A -> C. Thread 1 will notice its C is a duplicate and discard it. Now any error path involving C will trace back through the A -> B prefix rather than simply A.

There are a couple of ways I can think of solving this, neither of them good:

  1. When de-duping against an existing state, update its previous pointer (or depth member) if the duplicate has a shorter path. This introduces pointer chasing overhead in the case where we don't have a depth member as well as some interesting race conditions with updating a pointer that may be being walked elsewhere.
  2. Synchronise at the end of expanding each depth. This introduces an otherwise-unnecessary blocking condition and would need some careful interaction with rendezvous to avoid a deadlock. The advantage of this approach is that it guarantees we find the shortest path first, instead of having to juggle to fix this up later.

Bottom line, both of these introduce unacceptable overhead. I think we either need a third option or give up on this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant