-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fastsim/PF threading issues #3809
Fastsim/PF threading issues #3809
Conversation
A new Pull Request was created by @lgray (Lindsey Gray) for CMSSW_7_1_X. Fastsim/PF threading issues It involves the following packages: FastSimulation/Particle @nclopezo, @lveldere, @cmsbuild, @anton-a, @thspeer, @giamman, @slava77, @Degano can you please review it and eventually sign? Thanks. |
@Dr15Jones Also, looking at HcalChannelQuality and the root cause there... Seems to be simply a misuse of a mutable for silly reasons. I'll track it down and attach to this PR.... Probably reverting the PFRecHit producers back to stream modules. |
Figured out a bug on the plane. I will fix when I'm back in Geneva. |
See https://twiki.cern.ch/twiki/bin/view/CMSPublic/FWMultithreadedThreadSafeDataStructures#Lazy_caching_of_a_pointer for the much better way to cache a newly created object. |
Since
|
@Dr15Jones Ok, thanks. Today is pretty much done because of jetlag (at least right now, let's see at 3am). I'll submit new commits tomorrow morning CERN time. |
@Dr15Jones In the case of |
Hi Lindsay and Chris I realise that things need to move forward, However, I would really appreciate it if you could explain me a few things
What is the long term solution for this? Many thanks Lukas |
@lveldere The short answer is that there will be problems if the particle data table changes in one thread when another thread is reading it (reallocation across run boundary, etc.). Unless you think we should only ever run fastsim in single threaded mode we have to make it such that this cannot not happen. Moreover for CMS we have to ensure that the threads cannot communicate information to each other, since mixing information of lumisections/runs/events fundamentally a bad thing. A nice way to fix this, I think, would be to make the fast sim particle, the FamosManager, and FSim*, constructors take directly the ESHandle to the pdt, instead of asking for it through singleton. I think that would solve 99% of the issues being addressed here, and be a long term replacement for the patch we are putting in here. |
+1 I will communicate further with Lindsey to understand things in more detail |
Looks good to me. Thanks for doing this Lindsey, I owe you a Belgian beer. |
Fastsim/PF threading issues
@Dr15Jones
Fix singleton inside of fastim to be thread safe (memory barrier + mutex for possible loading).
Revert rechit producers back to standard EDProducers due to unsafe HcalChannelQuality ES product.
I'll try to make HcalChannelQuality safe, when I get a little more time.