Summary: | Deadlock between ProblemTreeViewer refresh and reconciler | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Nick Edgar <n.a.edgar> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | ispeters, Tod_Creasey |
Version: | 2.0 | ||
Target Milestone: | 2.0 F3 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Nick Edgar
2002-04-18 10:25:05 EDT
One possible fix would be for JavaReconcilingStrategy.reconcile() to obtain a lock on the JavaModelManager before the lock on the working copy. If a lock on the JavaModelManager is always obtained first, there seems to be little need for locking on the working copy (although you'd still want to synchronize on the manager in the same places as currently done for the working copies). This solution may limit concurrency, but is probably the safest approach. Problem should still be around. Why is the reconciling strategy taking a lock on the working copy ? Now, given this is a public object, we might want to avoid also synchronizing internally onto it... There is no point for us locking on the working copy before flushing it, indeed the internal cache removal is done by Openable#close which is synchronized already on the model manager. Removing this unnecessary lock. Same pattern was found onto the BufferCache. Fixed - will need JDT/UI to verify symptoms are gone |