[evaluator] Support parallel execution

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 343286 | | Status | NEW | | Importance | P3 enhancement | | Reported | Apr 19, 2011 12:22 EDT | | Modified | Aug 07, 2018 11:54 EDT | | Version | 3.1.0 | | See also | 535888 | | Reporter | Ed Willink |

Description

Java 7 provides a multithreading API. Use it for evaluation, but beware that OCL or EvaluationEnvironment or EnvironmentFactopry or EMF may not necessarily be thread safe without EMF transactions.

[eclipse-ocl-bot]

By Ed Willink on Jan 08, 2018 05:14

While the Pivot code nominally supports thread safe concurrent execution, it has never been tested and there is no design approach to enforce safety.

Recent work on Bug 529484 suggests that Notifier.eAdapters may be a particular fragile area. It was possible for a new EnvironmentFactory consumer to rescue it while it was being disposed.

[eclipse-ocl-bot]

By Ed Willink on Jun 17, 2018 03:08

Work on Bug 535888 identifies that ExpressionInOCL.ownedBody etc are assigned lazily but without a synchronization. User can worjaround with a warm up that fully assigns metamodel/library transients.

[eclipse-ocl-bot]

By Ed Willink on Jun 17, 2018 03:17

(In reply to Ed Willink from comment #2)

ExpressionInOCL.ownedBody etc ... without a synchronization

ParserContext would appear to have the lifetime to arbitrate thread-lockout via a passkey.

[eclipse-ocl-bot]

By Ed Willink on Aug 07, 2018 11:54

Work on an autogenerated loader (Bug 535888) executing in C identifies the need to synthesize access code and if we are interested in multi-threaded execution this needs to be threadsafe. Two problems to solve at once.

We can potentially have a single C/Java autogenerator to realize:

a) immutable data such as XxxTables can be static PODs in C, or statically constructed in Java

b) cached data such as ObjectState needs a full/idiomatic autogenerator

c) model accessors for 'eGet'/eSet' need an idiomatic generator