-
Notifications
You must be signed in to change notification settings - Fork 76
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
Add may-ever-have-been-locked digests for relational mutex-meet
#1286
Closed
Closed
Changes from 6 commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
78a8484
Add lock-digest example from more-traces
sim642 3f8c5d3
Add going multithreaded to lock-digest test
sim642 8e557ca
Fix lock-digest test
sim642 87e86ed
Add maylocksdigest analysis
sim642 90f1a62
Add MayLocksDigest query
sim642 21e0644
Add global invariant to maylocksdigest
sim642 65a572a
Merge branch 'mutex-meet-digest' into lock-digest
sim642 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
(** May lockset digest analysis ([maylocksdigest]). *) | ||
|
||
open Analyses | ||
open GoblintCil | ||
module LF = LibraryFunctions | ||
|
||
module Arg = | ||
struct | ||
module D = LockDomain.MayLocksetNoRW | ||
module P = IdentityP (D) | ||
|
||
module V = | ||
struct | ||
include StdV | ||
include LockDomain.Addr | ||
end | ||
module G = SetDomain.Make (D) | ||
|
||
let add (ctx: (D.t, G.t, D.t, V.t) ctx) (l,r) = | ||
let l's = ctx.global l in | ||
G.iter (fun l' -> | ||
if not (D.mem l ctx.local && not (D.mem l l')) then | ||
ctx.split (D.add l (D.union ctx.local l')) [] | ||
) l's; | ||
if D.mem l ctx.local then | ||
raise Deadcode | ||
else | ||
D.add l ctx.local (* for initial empty *) | ||
|
||
let remove (ctx: (D.t, G.t, D.t, V.t) ctx) l = | ||
ctx.sideg l (G.singleton ctx.local); | ||
ctx.local | ||
end | ||
|
||
module Spec = | ||
struct | ||
include LocksetAnalysis.MakeMay (Arg) | ||
let name () = "maylocksdigest" | ||
|
||
let threadenter ctx ~multiple lval f args = [ctx.local] | ||
|
||
let query (ctx: (D.t, _, _, _) ctx) (type a) (q: a Queries.t): a Queries.result = | ||
match q with | ||
| MayLocksDigest -> ctx.local | ||
| _ -> Queries.Result.top q | ||
end | ||
|
||
let _ = | ||
MCP.register_analysis ~dep:["mutexEvents"] (module Spec : MCPSpec) |
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
// PARAM: --set ana.activated[+] apron --set ana.relation.privatization mutex-meet-lock --set ana.activated[+] maylocksdigest --set ana.path_sens[+] maylocksdigest --set ana.path_sens[+] threadflag | ||
#include <pthread.h> | ||
#include <goblint.h> | ||
|
||
int g, h; | ||
pthread_mutex_t a = PTHREAD_MUTEX_INITIALIZER; | ||
|
||
void *t2(void *arg) { | ||
pthread_mutex_lock(&a); | ||
// wrong in more-traces! | ||
__goblint_check(h < g); // TODO | ||
pthread_mutex_unlock(&a); | ||
return NULL; | ||
} | ||
|
||
void *t1(void *arg) { | ||
pthread_t x; | ||
pthread_create(&x, NULL, t2, NULL); | ||
|
||
pthread_mutex_lock(&a); | ||
h = 11; g = 12; | ||
pthread_mutex_unlock(&a); | ||
return NULL; | ||
} | ||
|
||
void *t0(void *arg) { | ||
return NULL; | ||
} | ||
|
||
int main() { | ||
pthread_t x; | ||
pthread_create(&x, NULL, t0, NULL); // go multithreaded | ||
|
||
pthread_mutex_lock(&a); | ||
h = 9; | ||
g = 10; | ||
pthread_mutex_unlock(&a); | ||
|
||
pthread_create(&x, NULL, t1, NULL); | ||
return 0; | ||
} |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to still be implemented for the new digests. This is called$\mathsf{acc}$ in the paper, but is never defined there (?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
acc
is defined p.17 and eq (7), but it is specific to one instance, namely this thread id one, where things that are compatible digest-wise may still be ruled out as they are "accounted-for" in the local state (e.g. contributions of threads that have been joined).If one wants to speak at the level of digests, the appropriate notion is$[[u,act]]^\sharp_\mathcal{A}(A_0,A_1)$ being defined or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the implementation this
compatible
is the only thing that filters any reads out. Also being called "compatible" probably mislead me to think that's all there is to it. I'll rename it toaccounted_for
in #1278.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that the refinement should happen due to the lock operation of the digest itself, not
accounted_for
, somehow gets us back at analyses splitting each other's global unknowns.Or naively, the relational analysis needs to repeat the exact same lock operations on the digests to see which raise
Deadcode
as themaylocksdigest
analysis is already doing to find the new digests.I suspect the only reasonable way is to implement digests as a functor around an analysis, just like the paper proposes, to have direct and full control over these things in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually even that doesn't seem to work because instead of$m_g$ -s we implicitly lock and unlock them in each $\mathsf{lock}(m_g)$ operations has to split if there are multiple globals accessed in a single expression. The issue is that our $\mathsf{unlock}(m_g)$ also needs to be executed. Not to mention everything that happens after
read_global
/write_global
. But each of thosectx.split
is final: for the split-off branch, no more operations in the transfer function are executed, but the actual variable read andread_global
returns toRelationAnalysis
to do other global accesses or whatnot.Even if these digests were fully embedded into the privatization like TIDs have been so far, the same problem comes up:
read_global
needs to split into all of these cases and continue executing each one. We'd need CPS or list monad or multi-shot continuations to achieve that, all of which are major fundamental design changes.So I have no more realistic ideas on how to make these digests work at all. Unless anyone else does, we simply won't be able to implement them (especially in time for CAV).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can discuss this at the next GobCon. Maybe shooting for the general solution is overly ambitious, and we could investigate how to incorporate specific digests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't just a matter of going for the general solution because all of these problems have come up even with the specific simple may-ever-have-been-locked digests. Any other non-ego-lane-derived will inevitably have the very same fundamental problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, but there might be slight generalizations of ego-lane derived digests that maybe limit what is transmitted at
m_g
locks, which may still be helpful.The other thing is if we maybe are able to do some bookkeeping for these
m_g
locks and then dealy the actual split operation until later... But I'll have to think more deeply about it.