|Re: Deadlock in EMF transaction [message #1711971 is a reply to message #1711963]
||Tue, 20 October 2015 13:27
|| Christian Damus
Registered: July 2009
See some replies in-line, below.
On 2015-10-20 12:54:44 +0000, Laurent Fasani said:
> 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
> 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
> 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
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
> 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
> 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
> 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.01465 seconds