Community
Participate
Working Groups
Deadlocked threads as description: "Add Project to Server" Id=142 WAITING waiting on : java.util.concurrent.locks.ReentrantLock$FairSync@3aa129ee Locked by : AWT-EventQueue-1 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:201) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at org.eclipse.emf.internal.cdo.CDOStateMachine.lockView(CDOStateMachine.java:821) at org.eclipse.emf.internal.cdo.CDOStateMachine.readNoLoad(CDOStateMachine.java:357) at org.eclipse.emf.internal.cdo.view.CDOViewImpl.collectViewedRevisions(CDOViewImpl.java:1880) at org.eclipse.emf.internal.cdo.session.CDOSessionImpl.collectViewedRevisions(CDOSessionImpl.java:588) at org.eclipse.emf.internal.cdo.session.CDOSessionImpl.refresh(CDOSessionImpl.java:509) at org.eclipse.emf.internal.cdo.session.CDOSessionImpl.refresh(CDOSessionImpl.java:500) "AWT-EventQueue-1" Id=52 BLOCKED waiting on : org.eclipse.net4j.util.ref.ReferenceValueMap$Soft@53da267c Locked by : Add Project to Server at org.eclipse.emf.internal.cdo.view.CDOViewImpl.getObject(CDOViewImpl.java:985) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:968) at org.eclipse.emf.internal.cdo.view.CDOViewImpl.convertIDToObject(CDOViewImpl.java:1313) at org.eclipse.emf.internal.cdo.CDOStore.convertIdToObject(CDOStore.java:601) at org.eclipse.emf.internal.cdo.CDOStore.getContainer(CDOStore.java:126) at org.eclipse.emf.internal.cdo.CDOObjectImpl.eInternalContainer(CDOObjectImpl.java:594) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContainmentFeature(BasicEObjectImpl.java:855) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleContainer.dynamicGet(EStructuralFeatureImpl.java:1859) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1037) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013) at org.eclipse.emf.cdo.eresource.impl.CDOResourceNodeImpl.getFolder(CDOResourceNodeImpl.java:87) at org.eclipse.emf.cdo.eresource.impl.CDOResourceNodeImpl.getPath(CDOResourceNodeImpl.java:196) at org.eclipse.emf.cdo.eresource.impl.CDOResourceNodeImpl.getURI(CDOResourceNodeImpl.java:245) at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.getURI(CDOResourceImpl.java:241) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:364)
Thread "Add Project to Server" has CDOViewImpl.objects monitor and attempt to get View lock, while "AWT-EventQueue-1" thread has already View lock but requires to take CDOViewImpl.objects lock.
There is a comment in CDOViewImp.getObject: // Since getObject could trigger a read (ONLY when we load a resource) we NEED to make sure the state lock is // active. // Always use in the following order // 1- getStateLock().lock(); // 2- synchronized(objects) // DO NOT inverse them otherwise deadlock could occurred. Following this idea, easiest way to fix this is to obtain CDOView lock before "synchronized (objects)" in CDOViewImpl.collectViewedRevisions method. Perhaps, it worth to think about obtaining CDOView lock before each "synchronized (objects)" then?..
(In reply to comment #0) [...] > "AWT-EventQueue-1" Id=52 BLOCKED waiting on : > org.eclipse.net4j.util.ref.ReferenceValueMap$Soft@53da267c Locked by : Add > Project to Server Can you show the complete stack trace of this thread? I suspect that it contains a display.syncExec(...) which might not be a good idea...
No it doesn't contains this call. It is pure AWT/Swing application and deadlock is between two locks in CDO layer. It is situation, when synchronization is managed with two locks and these locks are attempted to be taken in random order. To avoid this we need reduce synchronization to one if possible, or ensure that synchronization appears in the same order always
Changing version to 3.0. Let's only use major versions to indicate the development stream. If more precise baseline info is needed let's insert a time stamp in a comment.
Created attachment 186254 [details] patch v1 Attached fix, which should solve situation described by stack trace. It simply ensures that monitor for objects and view reentrant lock doesn't intersect
Created attachment 186331 [details] Alternative Patch v1 Hi Egidijus, please review my counter proposal. I've removed two entire levels of syncronization.
Idea to eliminate double locking is great. Just one concern is about AbstractCDOView.getObjects(). It lets to escape "objects" from the guarding stateLock. Now you made synchronization where you find it is needed, but if we concern about the future usages, it worth to make this method private or return an "objects" copy or to have this objects map ConcurrentMap again. Comment issue: - implementation comment in method getObject(CDOID id, boolean loadOnDemand) about locks is stale in this case
The whole view synchronization is changed by bug 335080 *** This bug has been marked as a duplicate of bug 335080 ***
Closing.
