| Deadlock in EMF transaction [message #1711963] |
Tue, 20 October 2015 12:54  |
|
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  |
|
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.
|
|
|
Powered by
FUDForum. Page generated in 0.02777 seconds
] 
Search
Help
Register
Login
Home
