DeadLock in Lock class in conjunction with uiSafeAcquire

[pcdavid]

• 🆔 Bugzilla ID: #375161
• 📘 Project: Modeling / EMF Services / Transaction
• 🗓 Created: 2012-03-23T10:11:50Z
• ❓ Status: NEW /

[pcdavid]

Comment #0 on Fri Mar 23 2012 11:11:50 GMT+0100 (Central European Standard Time):

Build Identifier: Version: Indigo Service Release 2 Build id: 20120216-1857

We ran into a deadlock problem in conjunction with the org.eclipse.emf.transaction.util.Lock class and uiSafeAcquire in particular. I was able to create a demonstrator plugin and attached a threaddump from the same. I think this is a fundamental flaw of the Lock and should be fixed.

The scenario is:
- display thread tries to get the Lock exclusively using uiSafeAcquire, while another thread X already holds the Lock. The main thread stops and wait but processes the event loop.
- now yet another runnable is started using asyncExec and tries to get the Lock. This runnable is processed in the eventloop inside the still active uiSafeAcquire and stops since the lock is still held by X .
- now the very first Lock is released by Thread X.
- now two actions happen parallel (by chance one or the other first...):
   - (a) the AcquireJob gets the lock and then transfers it to the main thread.
   - (b) the inner event sees that it can get the lock and gets it.

Now what can happen here is: (a) gets the lock but hasn't transfered it yet. In this case (b) waits forever and the main thread is stalled. I could make the scenario even more reproducible by setting a breakpoint in  Lock, line 758 (before the transfer happens). On the other side the code will never deadlock if there is a breakpoint in Lock, line 195, because then (a) always completes before (b) actually tries to get the lock.


I don't have a solution for that. I was glad to be able to make this reproducible.

This problem we encountered first in internal development (here we solved it by not using the Lock class...) and now it seems to pop up again in the context of artop.org which uses EMF Transactions. 



Reproducible: Sometimes

Steps to Reproduce:
1. Install Indigo SR2
2. Drop the attached demonstrator plugin in the dropins folder
3. start Indigo
4. select menu "Sample Command -> Sample Command" and press ok. 
Repeat 4 until the system deadlocks. On my PC this happens often (more than 50% of all times) but this might actually be different on a different system.

---

Comment #1 on Fri Mar 23 2012 11:12:24 GMT+0100 (Central European Standard Time):

---

Comment #2 on Fri Mar 23 2012 11:13:13 GMT+0100 (Central European Standard Time):

---

Comment #3 on Fri Mar 23 2012 11:13:42 GMT+0100 (Central European Standard Time):

---

Comment #4 on Mon Aug 13 2012 17:55:24 GMT+0200 (Central European Summer Time):

Hi,

I have also a deadlock with the uiSafeAcquire() method, in context of CDO. Forking emf.transaction to call "transactionLock.acquire(!tx.isReadOnly());" instead of "transactionLock.uiSafeAcquire(!tx.isReadOnly());" fix the deadlock.
Which impacts could be to use "transactionLock.acquire()" instead of "transactionLock.uiSafeAcquire()"? Could we have a mean through a option to specify the TED to use "acquire()" instead of "uiSafeAcquire()" through a option?

---

Comment #5 on Sat May 14 2022 15:51:41 GMT+0200 (Central European Summer Time):

Eclipse EMF Transaction is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-transaction.

If this issue is relevant to you and still present in the latest release:

* Create a new issue at https://github.com/eclipse/emf-transaction/issues/.
  * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  * In the GitHub description, start with a link to this bugzilla ticket
  * Optionally add new content to the description if it can helps towards resolution
* Update bugzilla ticket
  * Add to "See also" property (up right column) the link to the newly created GitHub issue
  * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  * Set status as CLOSED MOVED

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Transaction will be archived and made read-only.