Deadlock issues was re: [cdt-dev] FYI, merged in a bunch of changes

[Chris Recoskie <recoskie@xxxxxxxxxx>]

I can't reproduce the deadlock issues at the office today as I have a much faster server connection here than via VPN, and this changes the timing so the deadlocks are difficult to reproduce here. I will try to reproduce the problem at home tonight.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

James Blackburn ---05/12/2010 04:42:37 AM---On 11 May 2010 23:55, Chris Recoskie <recoskie@xxxxxxxxxx> wrote: > - Reworked the resulting concurr

From:	James Blackburn <jamesblackburn@xxxxxxxxx>
To:	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date:	05/12/2010 04:42 AM
Subject:	Re: [cdt-dev] FYI, merged in a bunch of changes
Sent by:	cdt-dev-bounces@xxxxxxxxxxx

---

On 11 May 2010 23:55, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:
> - Reworked the resulting concurrency fixes - indexing and scanner discovery
> now synchronize on the project root as a scheduling rule. Original HEAD
> behaviour was to synch on the project's .settings folder for indexing, but
> that deadlocked with scanner discovery. James, you will probably want to
> take a look at what I did there and make sure you are comfortable with it,
> as I know you have been trying to relax the scheduling rules as much as
> possible. If you think it needs some rework let me know.

I had a quick look, would it be possible for you to attach
thread-dumps to a bug so we can better see where this is going wrong?
I haven't encountered any lock-ups in CDT 6/7.  (We use ILocks to lock
the project model, which have the benefit of deadlock detection /
resolution, and I know Toni and I have both fixed a couple ordering
issues here...)

The scheduling rule change in PDOMManager#addProject doesn't look
right to me.  Instead of asking the rule factory for a base rule it's
now fixed the at Project. Looking at Markus' logic, the MutliRule
created should always contain the project, and as more pessimistic
Team providers (e.g. CCRC) might return different scheduling rules for
refresh, it seems wrong not to involve them.

In CfgDiscoveredPathManager, you've replace the synchronized with a
project scoped sched rule.  This is to work around a deadlock in CDT
5, right? If we're just trying to enforce mutual exclusion, then ILock
would be better here (as done in SelectionListenerWithASTManager).
That way you still have deadlock detection/protection without the need
to know what rules the client code called requires, and without
checking into the workspace.

I'm a big one for collecting thread-dumps of lock-ups, it's a good
reminder / reference of how complicated the system is. Please do
attach them to bugs as and when you hit them!

Cheers,
James


> - Fixed remote indexing. Changes on HEAD that deprecated CodeReader broke
> the ability for remote translation units to provide the path to load the
> file content from. Added API to ITranslationUnit for this purpose.
>
> The tests all pass, but let me know if you run into any problems,
> particularly if you encounter any concurrency issues.
>
> FYI error parsing seems broken for remote projects. I intend to start
> looking into that tomorrow.
>
> ===========================
> Chris Recoskie
> Team Lead, IBM CDT and RDT
> IBM Toronto
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev