Make MuonTagger thread safe

[Dr15Jones]

Since the MuonTagger can be obtained via the EventSetup, the
const methods of the class must be thread safe. This required replacing
TRandom3 with C++11 random facility (since TRandom3 uses a global seed)
and using an std::mutex to protect MvaSoftMuonEstimator since the
way it interacts with TMVA::Reader is thread-unsafe.

[cmsbuild]

A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_7_4_X.

Make MuonTagger thread safe

It involves the following packages:

RecoBTag/SoftLepton

@cmsbuild, @cvuosalo, @nclopezo, @slava77 can you please review it and eventually sign? Thanks.
@ferencek, @acaudron, @pvmulder, @imarches this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[Dr15Jones]

please test

[cmsbuild]

The tests are being triggered in jenkins.

[VinInn]

a random (that is not so random) in reco ???
Could somebody explain the rationale of all this?

[Dr15Jones]

My understanding is all random numbers used in RECO are seeded deterministically. The reason is to guarantee we get the same results each time we run the RECO.

[slava77]

Yes, I confirm.
The RECO algorithms should in general not contain any randomness.
The best is if the random generator is not used at all, but in cases where it's used the algorithm seed is event/object-specific so that the results are reproducible.

[cmsbuild]

+1
Tested at: 6346525
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8304/7060/summary.html

[slava77]

+1

for #8304 6346525

in addition to jenkins, tested locally with higher stats in CMSSW_7_4_X_2015-03-14-1400 /test area sign529/

there are no changes in monitored quantities, which suggests that the code affected by the random number selection/generation is actually not triggered (requires multiple candidates).

I ran igprof on ttbar with pu35@25ns and observed some minor increase in CPU in the two affected modules (by this and #8284 PR)

        softPFMuonBJetTags       0.65958 ms/ev -> 0.853296 ms/ev
        softPFElectronBJetTags   2.2377 ms/ev -> 2.42587 ms/ev

the increase is, unconvincingly, matching the igprof cost in MvaSoftEleEstimator::mvaValue, but maybe a jitter. The random engine-related elements are not showing up in igprof.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs unless changes (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @ktf, @smuzaffar

[davidlange6]

+1