eclipse-ocl-bot
commented
2 hours ago By Ed Willink on Dec 31, 2016 04:14
If a deterministic Set order is based on object creation order, multi-threaded / multi-processor determinism is indeed very hard.
However if Set determinism is local with the output order determined by the input order, parallelism is not hindered. However certain commutative operations such as union/intersection are not commutative with respect to an input-determined order. Any commutation in optimizer/evaluator must be suppressed. Is it needed?
Perhaps debug options can specifically suppress commutation, or deliberately permute Sets randomly.
| --- | --- | | Bugzilla Link | 509726 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 27, 2016 12:14 EDT | | Modified | Dec 31, 2016 04:14 EDT | | Blocks | 509668 | | Reporter | Ed Willink |
Description
OCL defines the Set::asSequence order as undefined rather than indeterminate. Only the any iteration is indeterminate. Determinate with an underlying Java Set is hard so Classic OCL and then Pivot OCL treat unknown but determinate as too hard.
However once LazyIterables rather than Sets are used as intermediate values the order becomes much more determinsitic (on a single CPU). With EMF using EList for Sets, it should be possible to make OCL execution determinstic, albeit only known to someone prepared to study the prevailing chronology accidents.
"any" can be similarly determinate.
Therefore single threaded CPU Pivot OCL could be more strongly OCL compliant, even if OCL clarifies determinate. Users requiring determinate must not use multi-threaded. ?? could eve multi-threaded be determinate ??