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
RFC: DQMStore index logic rewrite #22307
Conversation
Also re-introduce the .cc file, implementations in the header are to likely to confuse the build system.
For now, step1 and Harvesting produce the same token, which is fine since we don't need to handle Sources and Harvesters in the same process yet. That way, the output modules will for sure wait for everything. There is a new type of token for the endRun, to make sure Lumi and Run transistions get ordered correctly.
Also protect the DQMStore using usesResource, since all of this is really dangerous.
Consume tokens, protect the DQMStore and watch all the transitions.
…bleMultiThread switch. Does not fix things, however.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22307/3508 |
A new Pull Request was created by @schneiml (Marcel Schneider) for master. It involves the following packages: Configuration/PyReleaseValidation @smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@@ -81,6 +81,8 @@ MEtoEDMConverter::MEtoEDMConverter(const edm::ParameterSet & iPSet) : | |||
produces<MEtoEDM<TString>, edm::Transition::EndLuminosityBlock>(sName); | |||
|
|||
consumesMany<DQMToken>(); | |||
consumesMany<DQMRunToken>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These need to be
consumesMany<DQMToken, edm::InLumi>();
consumesMany<DQMRunToken, edm::InRun>();
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in fact, I guess we could just use DQMToken
for both Run and Lumi MEs, and let the framework differentiate based on the InLumi
and InRun
flags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let me try. Maybe this fixes our problmes...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
obviously that would be too easy. Fixed, but #22281 continues...
@@ -25,5 +25,12 @@ class DQMToken | |||
DQMToken() {} | |||
}; | |||
|
|||
class DQMRunToken |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There really is not a need for a seperate type just for Run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dr15Jones I thought so. But having two produce
calls with the same Tokens gave me an error, and this was the quick fix.
@@ -81,6 +81,8 @@ MEtoEDMConverter::MEtoEDMConverter(const edm::ParameterSet & iPSet) : | |||
produces<MEtoEDM<TString>, edm::Transition::EndLuminosityBlock>(sName); | |||
|
|||
consumesMany<DQMToken>(); | |||
consumesMany<DQMRunToken>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in fact, I guess we could just use DQMToken
for both Run and Lumi MEs, and let the framework differentiate based on the InLumi
and InRun
flags.
run.moduleCallingContext()->moduleDescription()->id()); | ||
} | ||
|
||
void DQMEDAnalyzer::endRun(edm::Run const& run, edm::EventSetup const& setup) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to keep most methods - especially the empty ones - in the .h file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I in general prefer that -- but if it gives me linker errors, I happily put them into a .cc
file. My theory is that the build system gets more easily confused with implementation in headers (and honestly, I have no idea how this is supposed to work on the linker level, so putting back the .cc
file was the obvious option).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the build system does not get "confused".
If you put the implementation of a method inside the class body, e.g.
class Class {
public:
void some_method() { ... }
};
it is automatically inline
, and should not create linker problems.
If you put non-inline out-of-body implementation, like
class Class {
public:
void some_method();
};
void Class::some_method() { ... }
in the .h file, then you do get one version in each .cc file that includes it, and the linker will rightfully compile.
One other thing to pay attention to is if you have virtual methods, you may need to implement at least one of them in a .cc file, so the compiler knows "where" to emit the vtable and the type information.
I would be curious what problem you ran into here, and if we can find a less drastic solution than moving all methods' implementations to the .cc file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other thing to pay attention to is if you have virtual methods, you may need to implement at least one of them in a .cc file, so the compiler knows "where" to emit the vtable and the type information.
This one. So my gut feeling of putting things into a .cc file was justifed.
And yes, this inline story works fine as long as the methods are not virtual. Then it gets interesting.
|
||
DQMEDAnalyzer::DQMEDAnalyzer() { | ||
produces<DQMToken,edm::Transition::EndLuminosityBlock>(); | ||
produces<DQMRunToken,edm::Transition::EndRun>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dr15Jones when I remove the Run
in this line, I got an framework error, saying I cannot have more than one produce call for the same product. I guess I have to specify both transitions in one call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Our framework test works:
blToken_ = produces<ThingCollection, edm::Transition::BeginLuminosityBlock>("beginLumi"); |
However, that does use unique product instance names, which was not meant to be required.
@@ -92,7 +94,7 @@ void | |||
MEtoEDMConverter::beginJob() | |||
{ | |||
// Determine if we are running multithreading asking to the DQMStore. Not to be moved in the ctor | |||
enableMultiThread_ = dbe->enableMultiThread_; | |||
//enableMultiThread_ = dbe->enableMultiThread_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just delete the commented-out lines (and drop the empty methods)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
edm::EndLuminosityBlockProducer, | ||
edm::EndRunProducer> | ||
edm::EndRunProducer, | ||
edm::one::SharedResources> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the purpose of the SharedResources
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also do not understand its usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It gives the usesResource
call, which is a quick way to get a global lock for legacy stuff. Exactly what legacy DQM needs.
Though ideally, the final version of this PR will simply make that all thread save and we can get rid of usesResource("DQMStore")
everywhere.
I don't understand one thing: the DQMEDProducer now produces the token, and the METoEDM consumes it. |
They serve no purpose any longer, only cause confusion, and should be eradicated.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22307/3543 |
Pull request #22307 was updated. @smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please check and sign again. |
This is still WIP and probably does not even compile yet. |
... and fix the logic of it.
@fwyzard they are rather diverged by now, because I was doing things that are no longer covered by the title. I'll close it, and make a new PR once theses things are done. |
There might be more missing, per-lumi things, online, and multi-run harvesting. But the usual sequences run fine, now multi-threaded.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22307/3582 |
Pull request #22307 was updated. @smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please check and sign again. |
This PR attempts to complete the complete the conversion from #22157, via #22218 and #22243 et. al. It eliminates
streamId
andenableMultiThread
from the DQMStore.This needs to be merged/cherry-picked with #22319 and #22364, it adds another change on top: re-doing the logic that queries MEs out of the set in the DQMStore.
It needs to be discussed if the handling of the runNumber is actually what we want.
This is likely to break multi-run harvesting and online (needs testing).