eclipse-qvtd-bot
commented
13 hours ago By Ed Willink on Apr 20, 2019 02:56
Multiple partitions are necessary, but with distinct traces, since the 'definition' phase may be triggered from a selective diversity of invocation sites.
We may need a unique T{P,Q,true} mapping but it gets triggered from multiple sites so if a first stage creates T{P,-,null} for all P, we over create.
We need
- a distinct Tcall{P} that can be created on demand by one or more partitions
- non-unique Tcall{P} creates the unique T{P,-,null} key/map-entry
- if needed, lack-of-assignment evolves T{P,-,null} to T{P,-,false}
- lookup within one or more partitions predicates T{P,-,true} to discover Q.
Since there are two trace classes, non-unique Tcall{P} and unique T{P,Q,success} this cannot readily be solved by the MappingPartitioner / PartitionStrategy; the 'RegionPartitioner'/'RegionStrategy' as a rationalization of the InvocationAnalysis must create the two traces and partitions.
| --- | --- | | Bugzilla Link | 546596 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 19, 2019 11:12 EDT | | Modified | May 29, 2019 07:06 EDT | | See also | 546617 | | Reporter | Ed Willink |
Description
Once ATL2QVTr is improved we have the 'on-demand lookup idiom'.
a) a non-top-where caches an input-to-output equivalence\ b) other non-top-when invocations lookup the equivalence
But this gives two different invocation signatures:
a) partition{input, output} => success\ b) partition(input} => output, success/fail
These are different so the b) lookups miss the a) definitions.
Solution. We must always have two execution phases
1) activator: partition{input} 2) lookup: assign-output => success
The definition executes activator and residue.
The lookup executes activator and waits for success from elsewhere.
?? if we cannot prove that a success will come from elsewhere, we may have to have a lookup failure assignment to avoid a deadlock.
e.g.\ in pass <= M, 'activator's execute\ in M < pass < N, 'failure's execute\ in N <= pass, 'lookup's execute
Since we need partition{input} rather than partition{input, output} for non-top-when,, do we want to do the same for non-top-where too. Removes an irregularity and reduces the cardinality of uthe uniqueness signature, also avoiding conflicting ambiguities; or rather relegating conflicts to the standard re-assignment problem. The unqiueness is no longer shared for forward/backward incremental execution, but do we want to share at all. Surely we have separate forward/backward uniqueness with update of one needing to also update the other?