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
Make use of ProcessHistoryRegistry thread safe #927
Merged
ktf
merged 9 commits into
cms-sw:CMSSW_7_0_X
from
Dr15Jones:makeProcessHistoryRegistryThreadSafe
Sep 27, 2013
Merged
Make use of ProcessHistoryRegistry thread safe #927
ktf
merged 9 commits into
cms-sw:CMSSW_7_0_X
from
Dr15Jones:makeProcessHistoryRegistryThreadSafe
Sep 27, 2013
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To allow for thread-safe uses of the ProcessHistoryRegistry, the HistoryAppender no longer updates the ProcessHistoryRegistry to hold its appended history. Now it just returns a shared_ptr to the new or cached ProcessHistory. The shared_ptr is now owned by all Principals which are currently processing with that history. To simplify the sharing, we only cache the last ProcessHistory and no longer hold a map to all previously seen histories. This will allow us to have one HistoryAppender per Stream when used by the SubProcess.
The HistoryAppender now returns a shared_ptr<ProcessHistory const> so processHistoryPtr_ was changed to match. In addition, the fillPrincipal function no longer needs to modify the ProcessHistoryRegistry so the argument is now const.
The underlying Principal::fillPrincipal no longer modifies the ProcessHistoryRegistry and therefore takes a const reference. The fill*Principal methods were updated to match. This makes it clearer when reasoning about thread safety.
…egistry and RunPrincipal now holds the reducedProcessHistoryID -Principal::fillPrincipal no longer modifies the ProcessHistoryRegistry so now takes a const argument. fillRunPrincipal was updated to match. -The RunPrincipal now holds onto the reducedProcessHistoryID which is used to uniquely identify a Run. This makes identification of a Run easier for the SubProcess when it is time to write that Run.
Now has its own copy of the ProcessHistoryRegistry as preparation for thread-safety. As part of the change, now get the parent’s reducedProcessHistoryID from the RunPrincipal and not from the parent ProcessHistoryRegistry (which is no longer accessible). Full thread-safety will require each Stream to have its own ProcessHistoryRegistry and HistoryAppender.
…tory from RunPrincipal The SubProcess no longer takes a ProcessHistoryRegistry as an argument to its constructor since it now has its own internal copy. This avoids possible updates of a ProcessHistoryRegistry from different threads. In addition, RunPrincipal now holds its reducedProcessHistoryID so the EventProcessor now uses it from the RunPrincipal and not the Source.
The various fill*Principal member functions were changed to take a const ProcessHistoryRegistry. This change just swaps out using processHistoryRegistryForUpdate() and now use processHistoryRegistry() to make it clear that no change is required.
If the SubProcess had only one ProcessHistoryRegistry, that registry could be updating at the same time the HistoryAppender was reading from it. Therefore we need separate ProcessHistoryRegistry and HistoryAppender for each concurrent Run, Lumi and Stream.
Attempt to do a rebase failed without an adequate explanation from git as to why it failed.
+1 All framework unit tests pass. |
This pull request is fully signed and it will be integrated in one of the next IBs unless changes or unless it breaks tests. @ktf can you please take care of it? |
This pull request is fully signed and it will be integrated in one of the next IBs unless changes or unless it breaks tests. @ktf can you please take care of it? |
ktf
added a commit
that referenced
this pull request
Sep 27, 2013
…adSafe Make use of ProcessHistoryRegistry thread safe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Made sure that the ProcessHistoryRegistry was replicated sufficiently so that no thread would be updating a registry while a different thread could be attempting to read it.