Bugzilla – Full Text Bug Listing
| Summary: | Deadlock caused by unnecessary monitor synchronizations | ||
|---|---|---|---|
| Product: | [Modeling] EMF Services | Reporter: | Christian Damus <give.a.damus> |
| Component: | Transaction | Assignee: | Christian Damus <give.a.damus> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P1 | CC: | steveshaw, vramaswa |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 145880 | ||
Committed a fix, removing the synchronizations as indicated. *** Bug 145880 has been marked as a duplicate of this bug. *** Move to verified as per bug 206558. |
There are two occurrences of unnecessary Java monitor synchronizations in the Transaction API that cause deadlocks: - TransactionalEditingDomainImpl.deactivate(InternalTransaction) synchronizes on its transactionLock instance. Within this synch block, the post-commit is performed, which creates a read-only transaction and invokes listeners. If any of these listeners does a privileged runnable to synchronously execute some code on the Display thread, then deadlock occurs because of the next point - the Lock.getOwner() and Lock.getDepth() methods are synchronized. Thus, if the UI thread independently invokes some code that tries to get a read-only transaction on the editing domain, before it does a non-blocking wait for the lock, it calls Lock.getOwner() to see whether it already owns the lock. This method is synchronized, so deadlock occurs because another thread has the lock (previous point) and is trying to synchronously execute code on the display thread