Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Multiple XMI Resources concurrently
Multiple XMI Resources concurrently [message #834768] Mon, 02 April 2012 11:18 Go to next message
ModelGeek Mising name is currently offline ModelGeek Mising nameFriend
Messages: 550
Registered: June 2011
Senior Member
Hi,

I have an Ecore resource and using that i am trying to make multiple XMI resources using multithreading. I am using delegates to evaluate the instance model. If i use one thread every thing works fine but when i try to use multithreading then on creating xmi resource i get null pointer exception and setting delegate also becomes unable to calculate derivation statements.
Even if i will try to create XMI resource in synchronized block, it will be the same situation.
I need xmi resource as i am using allInstance statements.

Any idea?

Cheers,
Re: Multiple XMI Resources concurrently [message #834832 is a reply to message #834768] Mon, 02 April 2012 12:57 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

This is a known problem. The delegates are not multi-thread proof.

It is possible, no guarantees, that if you warm up your application by
invoking all possible delegates in one thread, you can then continue
your application in multiple threads.

Regards

Ed Willink

On 02/04/2012 12:18, ModelGeek Mising name wrote:
> Hi,
>
> I have an Ecore resource and using that i am trying to make multiple
> XMI resources using multithreading. I am using delegates to evaluate
> the instance model. If i use one thread every thing works fine but
> when i try to use multithreading then on creating xmi resource i get
> null pointer exception and setting delegate also becomes unable to
> calculate derivation statements.
> Even if i will try to create XMI resource in synchronized block, it
> will be the same situation.
> I need xmi resource as i am using allInstance statements.
>
> Any idea?
>
> Cheers,
>
Re: Multiple XMI Resources concurrently [message #834841 is a reply to message #834832] Mon, 02 April 2012 13:11 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising nameFriend
Messages: 550
Registered: June 2011
Senior Member
Thanks!

but can i create multiple XMI resources with multithreading like

URI uri = URI.createFileURI(number + "temp.xmi");
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi", new XMIResourceFactoryImpl());
Resource resource = resourceSet.createResource(uri);
resource.getContents().addAll(table.values());

this piece of code is defined in thread's run method but in some thread i get the NPE
on last line means resource object is null in some cases. Is it also known problem or i am doing something wrong?

Thanks alot for assitance

Cheers
Re: Multiple XMI Resources concurrently [message #835054 is a reply to message #834841] Mon, 02 April 2012 18:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

EMF claims to be threadsafe, and with the possible exception of
delegates, probably is.

Eclipse OCL makes no such claims and clearly isn't.

If you want to operate beyond the claimed capabilities, it is for you to
debug your problems, some of which may be yours rather than Eclipse OCL's.

I gave you a possible warm up procedure that just might work. It does
all the dangerous things in one thread, then does only safe things in
other threads. This strategy might avoid the problems. With knowledge of
your application you may be able to apply other strategies.

But if you really want multi-threading, you may want to fix the thread
safety and contribute a patch so that others can benefit.

Regards

Ed Willink

On 02/04/2012 14:11, ModelGeek Mising name wrote:
> Thanks!
>
> but can i create multiple XMI resources with multithreading like
>
> URI uri = URI.createFileURI(number + "temp.xmi");
> ResourceSet resourceSet = new ResourceSetImpl();
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi",
> new XMIResourceFactoryImpl());
> Resource resource = resourceSet.createResource(uri);
> resource.getContents().addAll(table.values());
>
> this piece of code is defined in thread's run method but in some
> thread i get the NPE
> on last line means resource object is null in some cases. Is it also
> known problem or i am doing something wrong?
>
> Thanks alot for assitance
>
> Cheers
Re: Multiple XMI Resources concurrently [message #835078 is a reply to message #835054] Mon, 02 April 2012 19:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Ed,

Comments below.

On 02/04/2012 11:36 AM, Ed Willink wrote:
> Hi
>
> EMF claims to be threadsafe, and with the possible exception of
> delegates, probably is.
What's the issue with setting delegates? I can see a race condition in
their initialization (EStructuralFeatureImpl.getSettingDelegate), but it
shouldn't matter if the delegate is initialized more than once...
>
> Eclipse OCL makes no such claims and clearly isn't.
>
> If you want to operate beyond the claimed capabilities, it is for you
> to debug your problems, some of which may be yours rather than Eclipse
> OCL's.
>
> I gave you a possible warm up procedure that just might work. It does
> all the dangerous things in one thread, then does only safe things in
> other threads. This strategy might avoid the problems. With knowledge
> of your application you may be able to apply other strategies.
>
> But if you really want multi-threading, you may want to fix the thread
> safety and contribute a patch so that others can benefit.
>
> Regards
>
> Ed Willink
>
> On 02/04/2012 14:11, ModelGeek Mising name wrote:
>> Thanks!
>>
>> but can i create multiple XMI resources with multithreading like
>>
>> URI uri = URI.createFileURI(number + "temp.xmi");
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xmi",
>> new XMIResourceFactoryImpl());
>> Resource resource = resourceSet.createResource(uri);
>> resource.getContents().addAll(table.values());
>>
>> this piece of code is defined in thread's run method but in some
>> thread i get the NPE
>> on last line means resource object is null in some cases. Is it also
>> known problem or i am doing something wrong?
>>
>> Thanks alot for assitance
>>
>> Cheers
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Multiple XMI Resources concurrently [message #835131 is a reply to message #835078] Mon, 02 April 2012 20:47 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Ed

On 02/04/2012 20:16, Ed Merks wrote:
>> EMF claims to be threadsafe, and with the possible exception of
>> delegates, probably is.
>
> What's the issue with setting delegates? I can see a race condition
> in their initialization (EStructuralFeatureImpl.getSettingDelegate),
> but it shouldn't matter if the delegate is initialized more than once...
I scanned the code in response to a similar query perhaps six months ago
and didn't get the impression that the code was inherently safe. It may
just be a benign race condition, but ... it's recent code. It was not
apparent that multi-threading was a design issue in the patches; if it
was, I would have tried harder on the OCL extension. I'm not sure that
multi-threading has ever been tested, so I think a possible
question-mark over delegate thread safety is appropriate to draw users
attention to.

Regards

Ed
Previous Topic:A strange result in OCL query
Next Topic:How define an ocl expression on type of an object
Goto Forum:
  


Current Time: Thu Apr 25 03:48:58 GMT 2024

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

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

Back to the top