Use SerialTaskQueues to protect shared resources (8_1) #15667
Merged
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
Unit test checks that no modules are run concurrently in a job where we only have legacy and one modules using shared resources.
-added move based functions -pushAndWait will rethrow an exception thrown in the lambda -added numberOfQueues() to be used by SharedResourcesAcquirer
Switched from using std::mutex to SerialTaskQueueChain to handle serialization when acquiring a shared resource. The SharedResourcesAcquirer now primarily holds a SerialTaskQueueChain and only holds mutexes for sharing between the Source and the DelayedReader. The SharedResourcesAcquirer are built to always contain at least one SerialTaskQueueChain since we no longer have a per module mutex and instead depends on having at least one queue. This initial implementation uses the SerialTaskQueueChain in a synchronous fashion. Future changes will move to asynchronous usage.
We also need to ignore the case where the result returns a very small number, i.e. one with 'e-' in its value.
The decrementing of the ref count on the waiting task must be done after the exception is set in order to avoid the case where the wait_for_all is released and we return from pushAndWait before the value is assigned to the now gone away stack variable.
No longer do a SerialTaskQueueChain::pushAndWait when we are requested to run a legacy or one module as part of a data prefetch. Now the task can return immediately and the module will be run once the its task reaches the head of the queue. This required moving the use of the SerialTaskQueueChain to the task launched after the prefetch has completed.
The mutexes were only used for an InputSource. Now the InputSource gets an explicit mutex along with its SharedResourcesAcquirer.
Now the signal is emitted right after the post prefetch task has started rather than just right before we are going to run the module.
Need to be sure all Services are active on a thread before emitting a signal since a Service listening to the signal may attempt to get another Service during that call.
Since the TriggerResults producer can always run concurrently, we need to relax the fraction of running 2 modules simultaneously from <0.01 to <0.02. This should avoid a false positive without missing a true failure.
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_8_1_X. It involves the following packages: FWCore/Concurrency @cmsbuild, @smuzaffar, @Dr15Jones, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
|
please test |
|
+1 |
|
The tests are being triggered in jenkins. |
cmsbuild
added
core-approved
fully-signed
and removed
core-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs after it passes the integration tests. This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @smuzaffar |
|
+1 |
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.
Replaced the use of std::recursive_mutexes with SerialTaskQueues when serializing modules to protect a shared resource. This allows the framework to only schedule a TBB task to run when that resource is free thereby opening up thread to do other work while the resource is in use.
This satisfies phase 1.75 of the threaded framework development plan.
This is a side-port from CMSSW_8_1_DEVEL_X