Closed hernanponcedeleon closed 1 week ago
Can you map back the event ids to the lines of code (I know that we do not have source information for Litmus code)?
23: read part of spinlock in P1 27: READ_ONCE in P1 14: WRITE_ONCE in P0
The example shows what I mentioned in #718 (and what I meant when saying "check the litmus tests manually").
Our analysis is likely correct and the "missing tuples" are not really missing, they are unnecessary.
The edge (27, 23)
is formed by a chain that goes through the first branch of P0
and is thus mutually exclusive to the 14: WRITE_ONCE
event. By performing suboptimal TC computation, in particular, by performing the computation twice, you end up with this imprecision.
This is because our current implementation is somewhat awkwardly implemented: it performs update operations that are a hybrid between a linear TC formulation (r+;r
) and the quadratic formulation (r+;r+
).
This causes it to degenerate to the quadratic solution when repeated unnecessarily often.
This quadratic solution is the least precise one and is also the one computed in the Datalog version.
While debugging the differences between the datalog and native backends for the RA in #708 , @DIvanov503 and I found what seems to be a bug in the computation of deltas for the transitive closure of relations.
This propagator is called twice (once by the RA and once by the encode via a call to
populateQueue
). AFAIK the second call should not add more may pairs (it could however drop some), but it indeed doesThe second one has pair
(14,23)
which could be derived from(14,27)
and(27,23)
. The first call has the later two, but missed the former.Here are a "minimal" model and test case to reproduce
and