Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Use a lock to protect access to collection from TROOT::GetListOfCleanups #67

Conversation

Dr15Jones
Copy link
Contributor

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
Contributor 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
Contributor 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
Contributor 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
Collaborator

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
Contributor

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