Home » Modeling » EMF » [EMF Transaction] About a deadlock and a monster UI thread
| [EMF Transaction] About a deadlock and a monster UI thread [message #425008] |
Thu, 13 November 2008 10:01  |
 Bernd Vogt
Messages: 34
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------030705010308050403030101
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
debugging a deadlock - that occurres during our model search - I came
across a realy big stack trace of the eclipse UI thread (see attachment).
Based on the assumption that the UI thread should basically dispatch (at
best) small runnables in a loop, I was a bit surprised about the
enormous size of the stack trace. Now my intention is to understand what
happend and if this behaviour is a danger or not.
Some analysis on my own results in the following steps:
- We run the whole model search process in a read-only transction to get
rid of concurrent modification exceptions (model search makes use of EMF
Query)
- During the search the eclipse search framework starts some UIJobs to
refresh the search view
- The code in the viewer-refresh-runnable (added by the UIJob) wants to
open a read-only transaction by itself in the UI thread and calls
Lock.uiSafeAcquire(...)
- Lock.uiSafeAcquire(...) is unable to get the lock while the search is
running (because the search runs exclusively)
- Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
implicitly calls EventLoopProgressMonitor.isCanceled()
- EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
-> At this point we have the behaviour that some runnables will be
dispatched into one another instead of one after another. In our case
this happens many times again and results in the enormous stack trace
Here I see the danger that runnables can be invoked with some locks or
monitors which they never excpect to. This can happen if the outer
runnable already owns a lock or monitor and than runs the event loop. (I
suspect that this behaviour leads to our deadlock but I'm realy not sure)
I also see that if Lock.uiSafeAcquire(...) won't run the event loop at
this time the UI seems to be frozen until the search has finished :-(
So, did we make anything wrong? I think it's not the best strategy to
run the search exclusively but what can we do get rid of CMEs during the
search?
Kind regards,
Bernd
--------------030705010308050403030101
Content-Type: text/plain;
name="trace.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="trace.txt"
Thread [main] (Suspended)
owns: TransactionImpl (id=166)
owns: SearchResultView (id=161)
owns: RunnableLock (id=167)
owns: TransactionImpl (id=168)
owns: RunnableLock (id=169)
owns: TransactionImpl (id=170)
owns: RunnableLock (id=171)
owns: TransactionImpl (id=172)
owns: RunnableLock (id=173)
owns: TransactionImpl (id=174)
owns: RunnableLock (id=175)
owns: TransactionImpl (id=176)
owns: RunnableLock (id=177)
owns: TransactionImpl (id=178)
owns: RunnableLock (id=179)
owns: TransactionImpl (id=180)
owns: RunnableLock (id=181)
owns: TransactionImpl (id=182)
owns: RunnableLock (id=183)
owns: TransactionImpl (id=184)
owns: RunnableLock (id=185)
owns: TransactionImpl (id=186)
owns: RunnableLock (id=187)
owns: TransactionImpl (id=188)
owns: RunnableLock (id=189)
owns: TransactionImpl (id=190)
owns: RunnableLock (id=191)
owns: TransactionImpl (id=192)
owns: RunnableLock (id=193)
owns: TransactionImpl (id=194)
owns: RunnableLock (id=195)
owns: TransactionImpl (id=196)
owns: RunnableLock (id=197)
owns: TransactionImpl (id=198)
owns: RunnableLock (id=199)
owns: TransactionImpl (id=200)
owns: RunnableLock (id=201)
owns: TransactionImpl (id=202)
owns: RunnableLock (id=203)
owns: TransactionImpl (id=204)
owns: RunnableLock (id=205)
owns: TransactionImpl (id=206)
owns: RunnableLock (id=207)
owns: TransactionImpl (id=208)
owns: RunnableLock (id=209)
owns: TransactionImpl (id=210)
owns: RunnableLock (id=211)
owns: TransactionImpl (id=212)
owns: RunnableLock (id=213)
owns: TransactionImpl (id=214)
owns: RunnableLock (id=215)
owns: TransactionImpl (id=216)
owns: RunnableLock (id=217)
owns: TransactionImpl (id=218)
owns: RunnableLock (id=219)
owns: TransactionImpl (id=220)
owns: RunnableLock (id=221)
owns: TransactionImpl (id=222)
owns: RunnableLock (id=223)
owns: TransactionImpl (id=224)
owns: RunnableLock (id=225)
owns: TransactionImpl (id=226)
owns: RunnableLock (id=227)
owns: TransactionImpl (id=228)
owns: RunnableLock (id=229)
owns: TransactionImpl (id=230)
owns: RunnableLock (id=231)
owns: TransactionImpl (id=232)
owns: RunnableLock (id=233)
owns: TransactionImpl (id=234)
owns: RunnableLock (id=235)
owns: TransactionImpl (id=236)
owns: RunnableLock (id=237)
owns: TransactionImpl (id=238)
owns: RunnableLock (id=239)
owns: TransactionImpl (id=240)
owns: RunnableLock (id=241)
owns: TransactionImpl (id=242)
owns: RunnableLock (id=243)
owns: TransactionImpl (id=244)
owns: RunnableLock (id=245)
waiting for: Object (id=164)
Object.wait(long) line: not available [native method]
ThreadJob.joinRun(IProgressMonitor) line: 189
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
TransactionalComposedAdapterFactory<T>(ModelAccess).run(RunnableWithResult) line: 117
TransactionalComposedAdapterFactory<T>(TransactionalAdapterFactory <T>).adapt(Object, Object) line: 36
VisualRuleEditingDomainFactory$VisualRulesEditingDomain(Adap terFactoryEditingDomain).getParent(Object) line: 620
RuleSearchTreeContentProvider(AbstractVisualRulesTreeContent Provider).getParent(Object) line: 129
RuleSearchTreeContentProvider(AbstractVisualRulesTreeContent Provider).getElements(Object) line: 103
TreeViewer(StructuredViewer).getRawChildren(Object) line: 937
TreeViewer(ColumnViewer).getRawChildren(Object) line: 703
TreeViewer(AbstractTreeViewer).getRawChildren(Object) line: 1330
TreeViewer.getRawChildren(Object) line: 385
TreeViewer(AbstractTreeViewer).getFilteredChildren(Object) line: 636
TreeViewer(AbstractTreeViewer).getSortedChildren(Object) line: 602
TreeViewer(AbstractTreeViewer).updateChildren(Widget, Object, Object[], boolean) line: 2567
TreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1856
TreeViewer.internalRefreshStruct(Widget, Object, boolean) line: 711
TreeViewer(AbstractTreeViewer).internalRefresh(Widget, Object, boolean, boolean) line: 1831
TreeViewer(AbstractTreeViewer).internalRefresh(Object, boolean) line: 1787
TreeViewer(AbstractTreeViewer).internalRefresh(Object) line: 1773
StructuredViewer$7.run() line: 1430
TreeViewer(StructuredViewer).preservingSelection(Runnable, boolean) line: 1365
TreeViewer.preservingSelection(Runnable, boolean) line: 397
TreeViewer(StructuredViewer).preservingSelection(Runnable) line: 1328
TreeViewer(StructuredViewer).refresh(Object) line: 1428
TreeViewer(ColumnViewer).refresh(Object) line: 537
TreeViewer(StructuredViewer).refresh() line: 1387
RuleSearchTreeContentProvider(AbstractVisualRulesTreeContent Provider).elementsChanged(Object[]) line: 75
SearchResultView.elementsChanged(Object[]) line: 94
SearchResultView(AbstractTextSearchViewPage).runBatchedUpdat es() line: 1196
AbstractTextSearchViewPage.access$1(AbstractTextSearchViewPa ge) line: 1186
AbstractTextSearchViewPage$UpdateUIJob.runInUIThread(IProgre ssMonitor) line: 139
UIJob$1.run() line: 94
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(IProgressMonitor) line: 167
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 87
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 230
Lock.uiSafeAcquire(boolean) line: 404
TransactionalEditingDomainImpl.acquire(InternalTransaction) line: 541
TransactionalEditingDomainImpl.activate(InternalTransaction) line: 469
TransactionImpl.start() line: 184
TransactionalEditingDomainImpl.startTransaction(boolean, Map<?,?>) line: 385
TransactionalEditingDomainImpl.runExclusive(Runnable) line: 282
ModelAccess.run(RunnableWithResult) line: 117
ModelAccess.internalRun(TypedRunnable<T>) line: 208
ModelAccess.run(TypedRunnable<T>) line: 203
ExtendedProviderUtil.getAdapter(Notifier, Class, AdapterFactory) line: 50
NavigatorResourceListener$7.run() line: 258
NavigatorResourceListener.runUpdates(Collection) line: 795
NavigatorResourceListener.runPendingUpdates() line: 785
NavigatorResourceListener.access$11(NavigatorResourceListene r) line: 772
NavigatorResourceListener$16.run() line: 731
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 133
Display.runAsyncMessages(boolean) line: 3800
Display.readAndDispatch() line: 3425
EventLoopProgressMonitor.runEventLoop() line: 123
EventLoopProgressMonitor.isCanceled() line: 97
ThreadJob.isCanceled(IProgressMonitor) line: 132
ThreadJob.joinRun(
|
|
|
| Re: [EMF Transaction] About a deadlock and a monster UI thread [message #425027 is a reply to message #425008] |
Thu, 13 November 2008 14:23  |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Bernd,
See some comments in-line, below.
HTH,
Christian
Bernd Vogt wrote:
> Hi,
>
> debugging a deadlock - that occurres during our model search - I came
> across a realy big stack trace of the eclipse UI thread (see attachment).
Yes, the UI-safe acquisition strategy is tricky and can generate some
pretty cool phenomena, including inversion of the order in which display
Runnables execute (if they are doing transactions).
> Based on the assumption that the UI thread should basically dispatch (at
> best) small runnables in a loop, I was a bit surprised about the
> enormous size of the stack trace. Now my intention is to understand what
> happend and if this behaviour is a danger or not.
>
> Some analysis on my own results in the following steps:
>
> - We run the whole model search process in a read-only transction to get
> rid of concurrent modification exceptions (model search makes use of EMF
> Query)
Are you periodically calling TransactionalEditingDomain::yield() to give
other, reader threads a chance to play?
> - During the search the eclipse search framework starts some UIJobs to
> refresh the search view
Right ... these are the kind that will benefit from yielding.
> - The code in the viewer-refresh-runnable (added by the UIJob) wants to
> open a read-only transaction by itself in the UI thread and calls
> Lock.uiSafeAcquire(...)
> - Lock.uiSafeAcquire(...) is unable to get the lock while the search is
> running (because the search runs exclusively)
Right, but when the search yields, then these other jobs will get a
chance to run. The lock acquisition is fair, I think, so that actually
all of these jobs will be served in order until they either finish or
yield, themselves.
> - Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
> implicitly calls EventLoopProgressMonitor.isCanceled()
> - EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
Ick, I know. Not pretty ...
> -> At this point we have the behaviour that some runnables will be
> dispatched into one another instead of one after another. In our case
> this happens many times again and results in the enormous stack trace
Yes, and you will find, as I mentiened above, that these runnables
actualy end up being reversed (though, of course, a good event-driven
concurrent app will never depend on ordering).
> Here I see the danger that runnables can be invoked with some locks or
> monitors which they never excpect to. This can happen if the outer
> runnable already owns a lock or monitor and than runs the event loop. (I
> suspect that this behaviour leads to our deadlock but I'm realy not sure)
This is one reason why the Eclipse API discourages acquisition of locks
of any kind on the UI thread. Unfortunately, when it comes to
transactions, there isn't really an option ... that's one of the reasons
why the uiSafeAcquire() is so tricky.
> I also see that if Lock.uiSafeAcquire(...) won't run the event loop at
> this time the UI seems to be frozen until the search has finished :-(
That's why your search yields at frequent intervals, right? ;-)
> So, did we make anything wrong? I think it's not the best strategy to
> run the search exclusively but what can we do get rid of CMEs during the
> search?
I've been assuming that your search is not yielding. I hope that's the
case, because otherwise I've got to think hard again ... :-)
> Kind regards,
> Bernd
>
|
|
|
| Re: [EMF Transaction] About a deadlock and a monster UI thread [message #425044 is a reply to message #425027] |
Fri, 14 November 2008 10:05 |
Bernd Vogt
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi Christian,
yielding... You've realy got me there :-) I must admit that we havn't
used this feature until now. It's a realy good point you made. I'll tune
up our search with 'yield' and try again.
Many thanks for your detailed answer,
Bernd
Christian W. Damus wrote:
> Hi, Bernd,
>
> See some comments in-line, below.
>
> HTH,
>
> Christian
>
> Bernd Vogt wrote:
>> Hi,
>>
>> debugging a deadlock - that occurres during our model search - I came
>> across a realy big stack trace of the eclipse UI thread (see attachment).
>
> Yes, the UI-safe acquisition strategy is tricky and can generate some
> pretty cool phenomena, including inversion of the order in which display
> Runnables execute (if they are doing transactions).
>
>
>> Based on the assumption that the UI thread should basically dispatch
>> (at best) small runnables in a loop, I was a bit surprised about the
>> enormous size of the stack trace. Now my intention is to understand
>> what happend and if this behaviour is a danger or not.
>>
>> Some analysis on my own results in the following steps:
>>
>> - We run the whole model search process in a read-only transction to
>> get rid of concurrent modification exceptions (model search makes use
>> of EMF Query)
>
> Are you periodically calling TransactionalEditingDomain::yield() to give
> other, reader threads a chance to play?
>
>
>> - During the search the eclipse search framework starts some UIJobs to
>> refresh the search view
>
> Right ... these are the kind that will benefit from yielding.
>
>
>> - The code in the viewer-refresh-runnable (added by the UIJob) wants
>> to open a read-only transaction by itself in the UI thread and calls
>> Lock.uiSafeAcquire(...)
>> - Lock.uiSafeAcquire(...) is unable to get the lock while the search
>> is running (because the search runs exclusively)
>
> Right, but when the search yields, then these other jobs will get a
> chance to run. The lock acquisition is fair, I think, so that actually
> all of these jobs will be served in order until they either finish or
> yield, themselves.
>
>
>> - Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
>> implicitly calls EventLoopProgressMonitor.isCanceled()
>> - EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
>
> Ick, I know. Not pretty ...
>
>
>> -> At this point we have the behaviour that some runnables will be
>> dispatched into one another instead of one after another. In our case
>> this happens many times again and results in the enormous stack trace
>
> Yes, and you will find, as I mentiened above, that these runnables
> actualy end up being reversed (though, of course, a good event-driven
> concurrent app will never depend on ordering).
>
>
>> Here I see the danger that runnables can be invoked with some locks or
>> monitors which they never excpect to. This can happen if the outer
>> runnable already owns a lock or monitor and than runs the event loop.
>> (I suspect that this behaviour leads to our deadlock but I'm realy not
>> sure)
>
> This is one reason why the Eclipse API discourages acquisition of locks
> of any kind on the UI thread. Unfortunately, when it comes to
> transactions, there isn't really an option ... that's one of the reasons
> why the uiSafeAcquire() is so tricky.
>
>
>> I also see that if Lock.uiSafeAcquire(...) won't run the event loop at
>> this time the UI seems to be frozen until the search has finished :-(
>
> That's why your search yields at frequent intervals, right? ;-)
>
>
>> So, did we make anything wrong? I think it's not the best strategy to
>> run the search exclusively but what can we do get rid of CMEs during
>> the search?
>
> I've been assuming that your search is not yielding. I hope that's the
> case, because otherwise I've got to think hard again ... :-)
>
>
>> Kind regards,
>> Bernd
>>
|
|
|
| Re: [EMF Transaction] About a deadlock and a monster UI thread [message #425121 is a reply to message #425044] |
Fri, 14 November 2008 15:03 |
Bernd Vogt
Messages: 34
Registered: July 2009 |
Member |
|
|
Ok, yielding realy helped out. Not to avoid the deadlock... but to get
much more responce from the UI during the search. Thanks for the hint :-)
A workaround for our deadlock problem was to fire the search-result
listeners in the UI thread... Otherwise the search the UI thread get
jammed beacuase both want to acquire the lock for a read transaction and
the monitor for the SearchResultView but in reversed order...
The affected methods are AbstractTextSearchViewPage#postUpdate(...)
(invoked by the search thread) and
AbstractTextSearchViewPage#runBatchedUpdates() (invoked in the UI thread
by the AbstractTextSearchViewPage#UpdateUIJob). :-(
Regards,
Bernd
Bernd Vogt wrote:
> Hi Christian,
>
> yielding... You've realy got me there :-) I must admit that we havn't
> used this feature until now. It's a realy good point you made. I'll tune
> up our search with 'yield' and try again.
>
> Many thanks for your detailed answer,
> Bernd
>
>
> Christian W. Damus wrote:
>> Hi, Bernd,
>>
>> See some comments in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>> Bernd Vogt wrote:
>>> Hi,
>>>
>>> debugging a deadlock - that occurres during our model search - I came
>>> across a realy big stack trace of the eclipse UI thread (see
>>> attachment).
>>
>> Yes, the UI-safe acquisition strategy is tricky and can generate some
>> pretty cool phenomena, including inversion of the order in which
>> display Runnables execute (if they are doing transactions).
>>
>>
>>> Based on the assumption that the UI thread should basically dispatch
>>> (at best) small runnables in a loop, I was a bit surprised about the
>>> enormous size of the stack trace. Now my intention is to understand
>>> what happend and if this behaviour is a danger or not.
>>>
>>> Some analysis on my own results in the following steps:
>>>
>>> - We run the whole model search process in a read-only transction to
>>> get rid of concurrent modification exceptions (model search makes use
>>> of EMF Query)
>>
>> Are you periodically calling TransactionalEditingDomain::yield() to
>> give other, reader threads a chance to play?
>>
>>
>>> - During the search the eclipse search framework starts some UIJobs
>>> to refresh the search view
>>
>> Right ... these are the kind that will benefit from yielding.
>>
>>
>>> - The code in the viewer-refresh-runnable (added by the UIJob) wants
>>> to open a read-only transaction by itself in the UI thread and calls
>>> Lock.uiSafeAcquire(...)
>>> - Lock.uiSafeAcquire(...) is unable to get the lock while the search
>>> is running (because the search runs exclusively)
>>
>> Right, but when the search yields, then these other jobs will get a
>> chance to run. The lock acquisition is fair, I think, so that
>> actually all of these jobs will be served in order until they either
>> finish or yield, themselves.
>>
>>
>>> - Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
>>> implicitly calls EventLoopProgressMonitor.isCanceled()
>>> - EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
>>
>> Ick, I know. Not pretty ...
>>
>>
>>> -> At this point we have the behaviour that some runnables will be
>>> dispatched into one another instead of one after another. In our case
>>> this happens many times again and results in the enormous stack trace
>>
>> Yes, and you will find, as I mentiened above, that these runnables
>> actualy end up being reversed (though, of course, a good event-driven
>> concurrent app will never depend on ordering).
>>
>>
>>> Here I see the danger that runnables can be invoked with some locks
>>> or monitors which they never excpect to. This can happen if the outer
>>> runnable already owns a lock or monitor and than runs the event loop.
>>> (I suspect that this behaviour leads to our deadlock but I'm realy
>>> not sure)
>>
>> This is one reason why the Eclipse API discourages acquisition of
>> locks of any kind on the UI thread. Unfortunately, when it comes to
>> transactions, there isn't really an option ... that's one of the
>> reasons why the uiSafeAcquire() is so tricky.
>>
>>
>>> I also see that if Lock.uiSafeAcquire(...) won't run the event loop
>>> at this time the UI seems to be frozen until the search has finished :-(
>>
>> That's why your search yields at frequent intervals, right? ;-)
>>
>>
>>> So, did we make anything wrong? I think it's not the best strategy to
>>> run the search exclusively but what can we do get rid of CMEs during
>>> the search?
>>
>> I've been assuming that your search is not yielding. I hope that's
>> the case, because otherwise I've got to think hard again ... :-)
>>
>>
>>> Kind regards,
>>> Bernd
>>>
|
|
|
| Re: [EMF Transaction] About a deadlock and a monster UI thread [message #425124 is a reply to message #425121] |
Fri, 14 November 2008 15:17 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Bernd,
Hmmm ... yes, lock ordering issues aren't in scope for the Transaction,
API, I'm afraid. That basically has to be left to the client to ensure
consistent ordering, unless perhaps there be some utilities that we can
provide to simplify it.
Can you suggest any improvements that we can make? Perhaps something
that you can contribute? You've done a good job of ferreting out some
tricky issues (I remember an earlier conversation).
I certainly am glad that your responsiveness is improved, at least.
cW
Bernd Vogt wrote:
> Ok, yielding realy helped out. Not to avoid the deadlock... but to get
> much more responce from the UI during the search. Thanks for the hint :-)
>
> A workaround for our deadlock problem was to fire the search-result
> listeners in the UI thread... Otherwise the search the UI thread get
> jammed beacuase both want to acquire the lock for a read transaction and
> the monitor for the SearchResultView but in reversed order...
>
> The affected methods are AbstractTextSearchViewPage#postUpdate(...)
> (invoked by the search thread) and
> AbstractTextSearchViewPage#runBatchedUpdates() (invoked in the UI thread
> by the AbstractTextSearchViewPage#UpdateUIJob). :-(
>
> Regards,
> Bernd
>
>
> Bernd Vogt wrote:
>> Hi Christian,
>>
>> yielding... You've realy got me there :-) I must admit that we havn't
>> used this feature until now. It's a realy good point you made. I'll
>> tune up our search with 'yield' and try again.
>>
>> Many thanks for your detailed answer,
>> Bernd
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Bernd,
>>>
>>> See some comments in-line, below.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> Bernd Vogt wrote:
>>>> Hi,
>>>>
>>>> debugging a deadlock - that occurres during our model search - I
>>>> came across a realy big stack trace of the eclipse UI thread (see
>>>> attachment).
>>>
>>> Yes, the UI-safe acquisition strategy is tricky and can generate some
>>> pretty cool phenomena, including inversion of the order in which
>>> display Runnables execute (if they are doing transactions).
>>>
>>>
>>>> Based on the assumption that the UI thread should basically dispatch
>>>> (at best) small runnables in a loop, I was a bit surprised about the
>>>> enormous size of the stack trace. Now my intention is to understand
>>>> what happend and if this behaviour is a danger or not.
>>>>
>>>> Some analysis on my own results in the following steps:
>>>>
>>>> - We run the whole model search process in a read-only transction to
>>>> get rid of concurrent modification exceptions (model search makes
>>>> use of EMF Query)
>>>
>>> Are you periodically calling TransactionalEditingDomain::yield() to
>>> give other, reader threads a chance to play?
>>>
>>>
>>>> - During the search the eclipse search framework starts some UIJobs
>>>> to refresh the search view
>>>
>>> Right ... these are the kind that will benefit from yielding.
>>>
>>>
>>>> - The code in the viewer-refresh-runnable (added by the UIJob) wants
>>>> to open a read-only transaction by itself in the UI thread and calls
>>>> Lock.uiSafeAcquire(...)
>>>> - Lock.uiSafeAcquire(...) is unable to get the lock while the search
>>>> is running (because the search runs exclusively)
>>>
>>> Right, but when the search yields, then these other jobs will get a
>>> chance to run. The lock acquisition is fair, I think, so that
>>> actually all of these jobs will be served in order until they either
>>> finish or yield, themselves.
>>>
>>>
>>>> - Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
>>>> implicitly calls EventLoopProgressMonitor.isCanceled()
>>>> - EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
>>>
>>> Ick, I know. Not pretty ...
>>>
>>>
>>>> -> At this point we have the behaviour that some runnables will be
>>>> dispatched into one another instead of one after another. In our
>>>> case this happens many times again and results in the enormous stack
>>>> trace
>>>
>>> Yes, and you will find, as I mentiened above, that these runnables
>>> actualy end up being reversed (though, of course, a good event-driven
>>> concurrent app will never depend on ordering).
>>>
>>>
>>>> Here I see the danger that runnables can be invoked with some locks
>>>> or monitors which they never excpect to. This can happen if the
>>>> outer runnable already owns a lock or monitor and than runs the
>>>> event loop. (I suspect that this behaviour leads to our deadlock but
>>>> I'm realy not sure)
>>>
>>> This is one reason why the Eclipse API discourages acquisition of
>>> locks of any kind on the UI thread. Unfortunately, when it comes to
>>> transactions, there isn't really an option ... that's one of the
>>> reasons why the uiSafeAcquire() is so tricky.
>>>
>>>
>>>> I also see that if Lock.uiSafeAcquire(...) won't run the event loop
>>>> at this time the UI seems to be frozen until the search has finished
>>>> :-(
>>>
>>> That's why your search yields at frequent intervals, right? ;-)
>>>
>>>
>>>> So, did we make anything wrong? I think it's not the best strategy
>>>> to run the search exclusively but what can we do get rid of CMEs
>>>> during the search?
>>>
>>> I've been assuming that your search is not yielding. I hope that's
>>> the case, because otherwise I've got to think hard again ... :-)
>>>
>>>
>>>> Kind regards,
>>>> Bernd
>>>>
|
|
|
| Re: [EMF Transaction] About a deadlock and a monster UI thread [message #425127 is a reply to message #425124] |
Fri, 14 November 2008 15:49 |
Bernd Vogt
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi, Christian,
I agree with you that lock ordering problems aren't in the scope of the
Transaction API.
In my opinion the Lock.uiSafeAcquire(...) does the best it can do and
the implicit call to EventLoopProgressMonitor.runEventLoop() is more a
blessing than a harm. In my understanding the dispatching of the event
loop at this time will prevent many deadlocks in the UI between two
transaction.
Consider the situation that a thread appends a async runnable to the
event queue that wants to oben a read transaction and at the same time
another thread already works within a transaction and now appends a sync
runnable after the async runnable into the event queue... The first
runnable will never get the lock for the transaction and the second will
never be executed -> deadlock. But if the first runnable now dispatches
the event loop the second will be executed and then the first gets the
lock it needs :-)
Regards,
Bernd
Christian W. Damus wrote:
> Hi, Bernd,
>
> Hmmm ... yes, lock ordering issues aren't in scope for the Transaction,
> API, I'm afraid. That basically has to be left to the client to ensure
> consistent ordering, unless perhaps there be some utilities that we can
> provide to simplify it.
>
> Can you suggest any improvements that we can make? Perhaps something
> that you can contribute? You've done a good job of ferreting out some
> tricky issues (I remember an earlier conversation).
>
> I certainly am glad that your responsiveness is improved, at least.
>
> cW
>
> Bernd Vogt wrote:
>> Ok, yielding realy helped out. Not to avoid the deadlock... but to get
>> much more responce from the UI during the search. Thanks for the hint :-)
>>
>> A workaround for our deadlock problem was to fire the search-result
>> listeners in the UI thread... Otherwise the search the UI thread get
>> jammed beacuase both want to acquire the lock for a read transaction
>> and the monitor for the SearchResultView but in reversed order...
>>
>> The affected methods are AbstractTextSearchViewPage#postUpdate(...)
>> (invoked by the search thread) and
>> AbstractTextSearchViewPage#runBatchedUpdates() (invoked in the UI
>> thread by the AbstractTextSearchViewPage#UpdateUIJob). :-(
>>
>> Regards,
>> Bernd
>>
>>
>> Bernd Vogt wrote:
>>> Hi Christian,
>>>
>>> yielding... You've realy got me there :-) I must admit that we havn't
>>> used this feature until now. It's a realy good point you made. I'll
>>> tune up our search with 'yield' and try again.
>>>
>>> Many thanks for your detailed answer,
>>> Bernd
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Bernd,
>>>>
>>>> See some comments in-line, below.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>> Bernd Vogt wrote:
>>>>> Hi,
>>>>>
>>>>> debugging a deadlock - that occurres during our model search - I
>>>>> came across a realy big stack trace of the eclipse UI thread (see
>>>>> attachment).
>>>>
>>>> Yes, the UI-safe acquisition strategy is tricky and can generate
>>>> some pretty cool phenomena, including inversion of the order in
>>>> which display Runnables execute (if they are doing transactions).
>>>>
>>>>
>>>>> Based on the assumption that the UI thread should basically
>>>>> dispatch (at best) small runnables in a loop, I was a bit surprised
>>>>> about the enormous size of the stack trace. Now my intention is to
>>>>> understand what happend and if this behaviour is a danger or not.
>>>>>
>>>>> Some analysis on my own results in the following steps:
>>>>>
>>>>> - We run the whole model search process in a read-only transction
>>>>> to get rid of concurrent modification exceptions (model search
>>>>> makes use of EMF Query)
>>>>
>>>> Are you periodically calling TransactionalEditingDomain::yield() to
>>>> give other, reader threads a chance to play?
>>>>
>>>>
>>>>> - During the search the eclipse search framework starts some UIJobs
>>>>> to refresh the search view
>>>>
>>>> Right ... these are the kind that will benefit from yielding.
>>>>
>>>>
>>>>> - The code in the viewer-refresh-runnable (added by the UIJob)
>>>>> wants to open a read-only transaction by itself in the UI thread
>>>>> and calls Lock.uiSafeAcquire(...)
>>>>> - Lock.uiSafeAcquire(...) is unable to get the lock while the
>>>>> search is running (because the search runs exclusively)
>>>>
>>>> Right, but when the search yields, then these other jobs will get a
>>>> chance to run. The lock acquisition is fair, I think, so that
>>>> actually all of these jobs will be served in order until they either
>>>> finish or yield, themselves.
>>>>
>>>>
>>>>> - Now Lock.uiSafeAcquire(...) calls JobManager.beginRule(...) what
>>>>> implicitly calls EventLoopProgressMonitor.isCanceled()
>>>>> - EventLoopProgressMonitor.isCanceled() runs the SWT event loop...
>>>>
>>>> Ick, I know. Not pretty ...
>>>>
>>>>
>>>>> -> At this point we have the behaviour that some runnables will be
>>>>> dispatched into one another instead of one after another. In our
>>>>> case this happens many times again and results in the enormous
>>>>> stack trace
>>>>
>>>> Yes, and you will find, as I mentiened above, that these runnables
>>>> actualy end up being reversed (though, of course, a good
>>>> event-driven concurrent app will never depend on ordering).
>>>>
>>>>
>>>>> Here I see the danger that runnables can be invoked with some locks
>>>>> or monitors which they never excpect to. This can happen if the
>>>>> outer runnable already owns a lock or monitor and than runs the
>>>>> event loop. (I suspect that this behaviour leads to our deadlock
>>>>> but I'm realy not sure)
>>>>
>>>> This is one reason why the Eclipse API discourages acquisition of
>>>> locks of any kind on the UI thread. Unfortunately, when it comes to
>>>> transactions, there isn't really an option ... that's one of the
>>>> reasons why the uiSafeAcquire() is so tricky.
>>>>
>>>>
>>>>> I also see that if Lock.uiSafeAcquire(...) won't run the event loop
>>>>> at this time the UI seems to be frozen until the search has
>>>>> finished :-(
>>>>
>>>> That's why your search yields at frequent intervals, right? ;-)
>>>>
>>>>
>>>>> So, did we make anything wrong? I think it's not the best strategy
>>>>> to run the search exclusively but what can we do get rid of CMEs
>>>>> during the search?
>>>>
>>>> I've been assuming that your search is not yielding. I hope that's
>>>> the case, because otherwise I've got to think hard again ... :-)
>>>>
>>>>
>>>>> Kind regards,
>>>>> Bernd
>>>>>
|
|
|
Goto Forum:
Current Time: Tue Apr 16 08:05:04 GMT 2024
Powered by FUDForum. Page generated in 0.16089 seconds |
] 
Search
Help
Register
Login
Home
