Skip to content

Conversation

@Dr15Jones
Copy link
Collaborator

The protection of the collection returned from TROOT::GetListOfCleanups()
was insufficient since thread related crashes could still occur. This
commit protects all uses except for those from the GUI.

…ups()

The protection of the collection returned from TROOT::GetListOfCleanups()
was insufficient since thread related crashes could still occur. This
commit protects all uses except for those from the GUI.
@Dr15Jones
Copy link
Collaborator Author

@pcanal

@pcanal
Copy link
Member

pcanal commented Jun 15, 2015

unfortunately this is performance issue .. as this way of handling the problem basically serialize all destruction of object derived from TObject ... :( ... i.e. one need a performance read-write lock for a proper fix

@Dr15Jones
Copy link
Collaborator Author

CMS is seeing a crash originating from this container.

@pcanal
Copy link
Member

pcanal commented Jun 15, 2015

I am not surprised, this is a know problem. If the performance is acceptable for the CMS case, please use the patch. For the general case, we need more work on it.

@Dr15Jones
Copy link
Collaborator Author

How many TObjects get marked at 'kMustCleanup'? It is only under that condition that the lock will be taken in the destructor.

@pcanal
Copy link
Member

pcanal commented Jun 15, 2015

At the very least all objects associated with a TDirectory (including gROOT) and a TPad (most notably that mean histograms and trees).

@davidlt
Copy link
Contributor

davidlt commented Oct 13, 2015

ping^1

@vgvassilev
Copy link
Member

I guess this relates to #596. Maybe it'd be worth rebasing this PR.

@phsft-bot
Copy link

Can one of the admins verify this patch?

@pcanal
Copy link
Member

pcanal commented Jun 2, 2017

This patch will be superseded by work subsequent to #596

@davidlt
Copy link
Contributor

davidlt commented Jun 2, 2017

@pcanal does it incl. cms-sw@308daba ?
This is a part we still apply at CMS.

@pcanal
Copy link
Member

pcanal commented Jun 2, 2017

Yes, this patch will (eventually) also be unnecessary (i.e. replaced by taking a read lock at this point that might be turned into a write lock as needed).

@vgvassilev
Copy link
Member

Ok, shall we close it then?

@pcanal
Copy link
Member

pcanal commented Jun 4, 2017

I will close this on another related PR when a proper replacement is uploaded. This will serve as a signal to the author to replace their temporary work-around.

@pcanal pcanal changed the title Use a lock to protect access to collection from TROOT::GetListOfCleanups [WIP] Use a lock to protect access to collection from TROOT::GetListOfCleanups Aug 24, 2017
@etejedor
Copy link
Collaborator

Hi @pcanal, perhaps we can close this one already since it is superseded by the RWlock PRs you have been working on?

@pcanal
Copy link
Member

pcanal commented Jan 11, 2018

This is superseed by adding a thread-safe mode to some ROOT collection and updating the global lock to have a Read-Write behavior (and update RecursiveRemove and friends accordingly).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants