Community
Participate
Working Groups
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.
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.
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.
(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.
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
