Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Deadlock in EMF transaction
Deadlock in EMF transaction [message #1711963] Tue, 20 October 2015 12:54 Go to next message
Laurent Fasani is currently offline Laurent FasaniFriend
Messages: 159
Registered: October 2014
Senior Member
Hello,
This post is to catch the EMF expert attention on a deadlock that is reproduced in CDO context but that is not specific to CDO but to EMFT

Here is the post
https://www.eclipse.org/forums/index.php/m/1711921/#msg_1711921

To generalize the scenario in a EMFT world:
1- on ui thread, execute an EMFCommand which lasts long enough to do step2 (for example open a DialogBox in the Command which require user to close it)
2- meanwhile on an other thread, execute some code that take the lock on the transaction and execute an EMFCommand in a transaction.

Step1 is executed on UIThread and will require Transaction to apply changes

Step2 : In other thread, the lock is taken on the Transaction. If an EMFCommand is executed, during step2, it'll require the lock on UI because of TransactionalEditingDomainImpl.acquire which call Lock.uiAcquire.

The problem comes from that.
Why does TransactionalEditingDomainImpl.acquire need to call transactionLock.uiSafeAcquire(!tx.isReadOnly());?

EMFTransaction should not rely on the UIThread.

The https://bugs.eclipse.org/bugs/show_bug.cgi?id=375161 bug is opened to handle this issue.
In that ticket, Esteban DUGUEPEROUX, proposed to call transactionLock.acquire(!tx.isReadOnly()); instead through the usage of an option to avoid impact on existing EMFT client applications.

What do you think?
Thank a lot for your answer.


Laurent Fasani - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: Deadlock in EMF transaction [message #1711971 is a reply to message #1711963] Tue, 20 October 2015 13:27 Go to previous message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1199
Registered: July 2009
Location: Canada
Senior Member

Hi,

See some replies in-line, below.

HTH,

Christian


On 2015-10-20 12:54:44 +0000, Laurent Fasani said:

> Hello,
> This post is to catch the EMF expert attention on a deadlock that is
> reproduced in CDO context but that is not specific to CDO but to EMFT
>
> Here is the post
> https://www.eclipse.org/forums/index.php/m/1711921/#msg_1711921
>
> To generalize the scenario in a EMFT world:
> 1- on ui thread, execute an EMFCommand which lasts long enough to do
> step2 (for example open a DialogBox in the Command which require user
> to close it)

I always recommend not to initiate user interaction during the
execution of a command. It would be better to gather all user input in
the dialog from the UI action (handler of the menu/button/whatever
invocation) and then create and execute the EMF command based on the
user's responses.


> 2- meanwhile on an other thread, execute some code that take the lock
> on the transaction and execute an EMFCommand in a transaction.

Most people just execute the command on the UI thread if it was
initiated by a gesture in the UI, but if it does a lot of work that
needs progress display, then yes, it would be sidelined onto another
thread (usually a Job).


> Step1 is executed on UIThread and will require Transaction to apply changes
>
> Step2 : In other thread, the lock is taken on the Transaction. If an
> EMFCommand is executed, during step2, it'll require the lock on UI
> because of TransactionalEditingDomainImpl.acquire which call
> Lock.uiAcquire.

This approach is already broken: you have a CommandStack concurrently
executing two commands on different threads. Which command is at the
top of the undo stack? EMF does not support this, irrespective of
whether Transactions are involved.


> The problem comes from that.
> Why does TransactionalEditingDomainImpl.acquire need to call
> transactionLock.uiSafeAcquire(!tx.isReadOnly());?
>
> EMFTransaction should not rely on the UIThread.

It doesn't. The uiSafeAcquire method is deliberately named thus
because it employs a locking mechanism provided by Eclipse Platform
that, when the Eclipse UI framework is active, will ensure that when
transactions run on the UI thread, that the UI event queue remains
responsive.


> The https://bugs.eclipse.org/bugs/show_bug.cgi?id=375161 bug is opened
> to handle this issue.
> In that ticket, Esteban DUGUEPEROUX, proposed to call
> transactionLock.acquire(!tx.isReadOnly()); instead through the usage of
> an option to avoid impact on existing EMFT client applications.

I'm surprised that this would prevent deadlock. Or just it just let
the Job Manager arbitrarily break the deadlock by breaking one of the
locks involved?


> What do you think?

I think that getting the UI interactions out of the EMF commands should
help, if not actually fix the problem. I am concerned about EMF
commands being executed on background threads: the operation history
notifies the UI about executions and changes in the undo/redo stacks.
Is it safe to do that on a background thread in the first place?


> Thank a lot for your answer.
Previous Topic:[CDO/Dawn] Deadlocking w/ Display, Dawn's handleViewInvalidationEvent, & CDO's InvalidationRunna
Next Topic:string
Goto Forum:
  


Current Time: Thu Oct 17 01:35:27 GMT 2019

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

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

Back to the top