Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Parallelized execution of OCL queries
Parallelized execution of OCL queries [message #666182] Tue, 19 April 2011 12:25 Go to next message
Christian Saad is currently offline Christian Saad
Messages: 38
Registered: July 2009
Member
Hi,

I'm currently having a a bit of a hard time trying to parallelize the execution of OCL queries. The problem seems to be the evaluation environment which exists only once for each query and therefore becomes inconsistent if a query is executed in different contexts at the same time. However since there may be a lot of model objects in my use case I'd like to avoid creating and parsing a seperate query for each one.
Is there a way around this problem?

Thanks,
Chris
Re: Parallelized execution of OCL queries [message #666186 is a reply to message #666182] Tue, 19 April 2011 12:32 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Chris,

off the top of my head, I suggest first parsing the expression, using e.g., OCL.newInstance().createOCLHelper().createQuery(String). You can then create multiple OCL objects using OCL.newInstance() and evaluate the single OCLExpression using OCL.evaluate(OCLExpression). This should also work in parallel as the different OCL objects will create their own, independent evaluation environments.

Best,
-- Axel
Re: Parallelized execution of OCL queries [message #666268 is a reply to message #666186] Tue, 19 April 2011 16:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4098
Registered: July 2009
Senior Member
Hi Chris

Axel's suggestions sem like your best bet. The OCL facade seems to only
allow a single EvaluationEnvironment and I feel your problem should be
soluble with one OCL, one EnironmentFactory, one Environment, and
multiple EvaluationEnvironments. If you use your own EnvironmentFactory
so that you can keep a reference to it, you may be able to get away with
a distinct nested EvaluattionEnvironment per query. But the
threadsafe-ness of the OCL classes is untested, and I'm not certain that
you will find the underlying EMF usage threadsafe in the absence of EMF
Transaction support.

Thanks for the prod. I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=343286 to take this and
the Java 7 multi-threading capabilities seriously (for Juno).

Regards

Ed Willink


On 19/04/2011 13:32, Axel Uhl wrote:
> Chris,
>
> off the top of my head, I suggest first parsing the expression, using
> e.g., OCL.newInstance().createOCLHelper().createQuery(String). You can
> then create multiple OCL objects using OCL.newInstance() and evaluate
> the single OCLExpression using OCL.evaluate(OCLExpression). This
> should also work in parallel as the different OCL objects will create
> their own, independent evaluation environments.
>
> Best,
> -- Axel
Re: Parallelized execution of OCL queries [message #666285 is a reply to message #666268] Tue, 19 April 2011 18:07 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Please also note that the delegates stuff and internal caching of operation and property bodies is most likely not thread-safe yet either.
Re: Parallelized execution of OCL queries [message #666299 is a reply to message #666285] Tue, 19 April 2011 19:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
Axel,

In general an Ecore model should be read-only thread safe so I would
hope these aspects are as well. If not, we should look at addressing
that. At a glance it looks like they'd be safe although there
definitely could be race conditions, it doesn't look like it would
matter who wins the race.


Axel Uhl wrote:
> Please also note that the delegates stuff and internal caching of
> operation and property bodies is most likely not thread-safe yet either.
Re: Parallelized execution of OCL queries [message #666378 is a reply to message #666182] Wed, 20 April 2011 08:39 Go to previous messageGo to next message
Christian Saad is currently offline Christian Saad
Messages: 38
Registered: July 2009
Member
Hi all,

thanks for your help. I've tried Axel's suggestion and so far it seems to work. In my implementations, I never had any problems relating to multi thread read-only access to EMF models.
Unfortunately a similar problem exists when using QVT's OCL implementation with the OCLEnvironmentWithQVTAccessFactory instead. As far as I can tell this may be due to the CallHandler for Java black box operations not being thread safe.

Regards,
Chris
Re: Parallelized execution of OCL queries [message #666396 is a reply to message #666299] Wed, 20 April 2011 10:00 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Ed,

I was thinking of the on-demand OCL compilation taking place when a delegate is first used. There are OCL-internal caches remembering the resulting AST, so the compilation doesn't have to be repeated upon each use of the delegate. I was trying to say that this caching hasn't been designed and tested for thread-safety yet, AFAIK.

Best,
-- Axel
Re: Parallelized execution of OCL queries [message #666409 is a reply to message #666182] Wed, 20 April 2011 11:13 Go to previous messageGo to next message
Christian Saad is currently offline Christian Saad
Messages: 38
Registered: July 2009
Member
The culprit in the case of QVT seems to be the fArgs variable in the JavaMethodHandlerFactory. I managed to change the implementation but unfortunately only by using reflection to replace the default JavaBlackboxProvider with a custom one and duplicating a lot of internal classes. Maybe this global variable could be removed in future versions of QVT.
Re: Parallelized execution of OCL queries [message #667344 is a reply to message #666299] Thu, 28 April 2011 08:53 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4098
Registered: July 2009
Senior Member
Hi Ed

An Ecore model might be expected to be read-only threadsafe, but
anything that involves a cache offers an opportunity for problems. Even
if a race is ultimately resolved by whoever wins, there is a risk that
the competitors get to use their competing contributions, one of which
will probably have a broken eContainer() chain. For a race hierarchy,
not all races may be won by the same competitor so the winners may not
form a consistent set of objects.

EMF is much more than read only models, so I suspect that a review is
needed at least to establish the boundary at which EMF is intrinsically
threadsafe, and what corrections may be necessary to ensure that all
functionality is threadsafe when supervised by EMF Transactions.

No methods in ResourceSetImpl or EcorePlugin are synchronized, so there
are certainly opportunities for unthinking abuse.

Regards

Ed

On 19/04/2011 20:42, Ed Merks wrote:
> Axel,
>
> In general an Ecore model should be read-only thread safe so I would
> hope these aspects are as well. If not, we should look at addressing
> that. At a glance it looks like they'd be safe although there
> definitely could be race conditions, it doesn't look like it would
> matter who wins the race.
>
>
> Axel Uhl wrote:
>> Please also note that the delegates stuff and internal caching of
>> operation and property bodies is most likely not thread-safe yet either.
Previous Topic:Activating container() support in OCL*Delegates and OCLConsole
Next Topic:Information about processing OCL constraints
Goto Forum:
  


Current Time: Sun Oct 26 03:46:04 GMT 2014

Powered by FUDForum. Page generated in 0.09753 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software