Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] PDom locking, lifecycle of PDom objects 
Hi,
I just figured out that having read-locks on multiple PDOMs should not
be a problem, as long as no-one tries to obtain write-locks or a
combination of write- and read-locks on multiple PDOM databases. I will
put a note into the documentation of IPDOM.acquireWriteLock().

With that I have a safe solution for computing the Call Hierarchy, which
makes me happy :-)!

---------------------------------------------
On the other hand there is a remaining issue:
---------------------------------------------
When you obtain an IASTTranslationUnit by using the method
'ILanguage.getASTTranslationUnit(...)' with the option
'ILanguage.AST_USE_INDEX' you need to obtain a read-lock, as the
resulting translation unit can contain elements from the PDOM. This is
far from obvious and is not done in various places of the CDT source
code:

ASTProvider.java - org/eclipse/cdt/internal/ui/editor
OpenDefinitionAction.java - org/eclipse/cdt/internal/ui/search/actions
PDOMFastHandleDelta.java -
org/eclipse/cdt/internal/core/pdom/indexer/fast
PDOMFastIndexerJob.java -
org/eclipse/cdt/internal/core/pdom/indexer/fast
PDOMSearchElementQuery.java - org/eclipse/cdt/internal/ui/search
PDOMSearchTextSelectionQuery.java - org/eclipse/cdt/internal/ui/search

Markus.
 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> Sent: Dienstag, 05. September 2006 16:48
> To: CDT General developers list.
> Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> 
> Interesting idea. I've never used adaptBinding that way (I 
> don't think...).
> 
> At any rate, once you get the new binding, you can release 
> the old one and
> the unlock the old PDOM.
> 
> Doug Schaefer
> QNX Software Systems
> Eclipse CDT Project Lead
> http://cdtdoug.blogspot.com
>  
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Schorn, Markus
> Sent: Tuesday, September 05, 2006 10:31 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> 
> The point is that definitions for references are not necessarily
> part of the same project:
> 
> Project A:
>   File: library.h:  void lib_func();
>   File: library.c:  void lib_func() {}
>   File: testLibrary.c: int main(int argc, char** argv) { lib_func();} 
> 
> Project B:
>   File: main.c:  int main(int argc, char** argv) { lib_func();}
> 
> In case I want to show the call hierarchy for 'lib_func', I need to
> search the PDom of project A and B.
> 
> I currently make this happen by using PDOMLinkage.adaptBinding() to
> convert the PDOMBinding from the one PDOM to the other. 
> 
> Markus.
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> > Sent: Dienstag, 05. September 2006 15:19
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > 
> > Hmm, I'm a little confused. PDOM's don't know about 
> > eachother. So I'm not
> > sure what you meant by (c). Once you have the IASTName, you ask the
> > IPDOMResolver to resolve the IBinding, then from there you 
> > can navigate to
> > references or definitions or declarations. You would have to 
> > do that for
> > each PDOM. It certainly wasn't my intention that you can use 
> > PDOM objects
> > from one PDOM to navigate to objects in another PDOM. Given 
> > that, you would
> > only need to lock one PDOM at a time.
> > 
> > Doug Schaefer
> > QNX Software Systems
> > Eclipse CDT Project Lead
> > http://cdtdoug.blogspot.com
> >  
> > 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > Behalf Of Schorn, Markus
> > Sent: Tuesday, September 05, 2006 8:15 AM
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > 
> > Doug,
> > 
> > I avoided using PDom objects in the model of the Call Hierarchy,
> > so that should be ok. 
> > Yet I work with the PDOM to find the references. For that I have
> > to access multiple PDOMs and I can see a problem with that, because
> > I cannot obtain the locks on multiple PDOMs without taking the risk
> > of a deadlock. 
> > 
> > Here is what I do
> > (a) convert input from ICElement to IASTName.
> > (b) find references for the IASTName in PDom.
> > (c) find definitions for references in multiple PDoms
> > (d) convert definitions to ICElements.
> > 
> > (c) is the problematic step as I have to use the reference found in
> >     a PDom to search for definitions in all other PDoms.
> > 
> > I'll be happy to discuss this at the summit.
> > 
> > Markus.
> > 
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx 
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> > > Sent: Dienstag, 05. September 2006 13:42
> > > To: CDT General developers list.
> > > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > > 
> > > Sorry, Markus, I was trying very hard not to work on the 
> > > holiday yesterday
> > > ;). 
> > > The PDOM is probably immature in this area, which is one 
> > > reason why the
> > > Index View is hidden and not recommended for heavy use. The 
> > > PDOM does have a
> > > read/write lock on it. While you are looking at objects you 
> > > should have the
> > > read lock turned on. You shouldn't keep them around long 
> > > term. That is the
> > > role of the ICElement objects. That comes back to the need to 
> > > be able to
> > > create ICElement objects from the PDOM and to update them 
> > > based on PDOM
> > > updates. That would probably make your life easier.
> > > 
> > > This is something we need to talk about at the Summit. I'll have a
> > > presentation there that will hopefully clarify what the 
> > > architecture is
> > > supposed to be.
> > > 
> > > Doug Schaefer
> > > QNX Software Systems
> > > Eclipse CDT Project Lead
> > > http://cdtdoug.blogspot.com
> > >  
> > > 
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx 
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > > Behalf Of Schorn, Markus
> > > Sent: Tuesday, September 05, 2006 4:19 AM
> > > To: CDT General developers list.
> > > Subject: RE: [cdt-dev] PDom locking, lifecycle of PDom objects
> > > 
> > > Hi Doug,
> > > please help me out on this, I really need to understand how 
> > > to correctly
> > > use locks on the PDom. I try to restate my question:
> > > 
> > > The implementation of the Call Hierarchy has the need to work 
> > > with multiple PDoms, because such hierarchies may span 
> over multiple
> > > projects. I must not simultaneously hold locks of multiple PDoms
> > > as this would lead to dead-locks. So I have to avoid locks where
> > > possible and I have to understand under which circumstances this
> > > is reasonable to do.
> > > 
> > > If there is no safe way to work with multiple PDoms we should
> > > make changes to our architecture. That's why I'd like to 
> understand
> > > this as soon as possible.
> > > 
> > > Markus.
> > > 
> > > > -----Original Message-----
> > > > From: cdt-dev-bounces@xxxxxxxxxxx 
> > > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
> > > > Sent: Montag, 04. September 2006 15:26
> > > > To: CDT General developers list.
> > > > Subject: [cdt-dev] PDom locking, lifecycle of PDom objects
> > > > 
> > > > Hi,
> > > > I am trying to understand how to safely use the PDom. I have 
> > > > a bunch of
> > > > questions. I can only ask the first one, as the next one will 
> > > > depend on
> > > > the first answer. 
> > > > 
> > > > Objects obtained by the PDOM (e.g. PDOMName) will actually 
> > > access the
> > > > database when I invoke methods (e.g. 
> > > PDOMName.toCharArray()) on them.
> > > > What happens if the database was modified after the PDOM 
> > object was
> > > > handed to me?
> > > > 
> > > > Markus.
> > > > _______________________________________________
> > > > 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
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>

Back to the top