Description Jason Sholl 2010-05-11 16:27:03 EDT

The deadlock is because of synchronization method around the addExtender() and notification methods.  I hit this in debug mode and then attempted to fix it while I was in debug mode (which is why the stacks are out of date).  The following two threads are attempting to load and unload the same resource at the same time.  In order for this to proceed, first the load needs to finish and then the unload needs to occur.

The ModalContext thread is performing the unload and is holding the ResourceSetWorkbenchSynchronizer lock while it waits for the ResourceSyncrhonizedIsLoadAdapter.loadingLock.  The Main thread is performing the load and has the ResourceSyncrhonizedIsLoadAdapter.loadingLock but needs the ResourceSetWorkbenchSynchronizer lock in order to complete the load.

The only reason a ResourceSetWorkbenchSynchronizer is necessary is to protect the set of extenders during notifications and adds.  The fix is to remove this lock and build the protection directly into the Set.  This protect works as follows:  before iterating for notification, the set is put in queuing mode.  While in queuing mode, modifications will not be pushed down to the set but instead held onto temporarily.  After iterating for notification, the set is taken out of queuing mode.  Any additional adds are then committed to the set and then iterated over in the same fashion (put the set in queuing mode, perform the iteration, and then check to see if anything else came in).

We decided to go with this new queuing mechanism rather than other constructs like listener lists or making copies during the notification because the notificaiton methods are called very frequently and a copy would be too slow.  Also, now with the synchronization removed from ResourceSetWorkbenchSynchronizer special care needs to be taken to ensure no event notifications are lost in the event that an add occurs during a notification.  This new mechanism will protect against these scenarios while still avoiding the deadlock.