Skip to content
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

Closed
wants to merge 18 commits into from

Conversation

schneiml
Copy link
Contributor

@schneiml schneiml commented Feb 22, 2018

This PR attempts to complete the complete the conversion from #22157, via #22218 and #22243 et. al. It eliminates streamId and enableMultiThread 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).

Dmitrijus Bugelskis and others added 8 commits February 21, 2018 17:05
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.
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @schneiml (Marcel Schneider) for master.

It involves the following packages:

Configuration/PyReleaseValidation
DQMServices/Components
DQMServices/Core
DataFormats/Histograms
Validation/RecoTau

@smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please review it and eventually sign? Thanks.
@ghellwig, @barvic, @makortel, @felicepantaleo, @rovere, @Martin-Grunewald, @ebrondol this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

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>();
Copy link
Contributor

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>();

Copy link
Contributor

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.

Copy link
Contributor Author

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...

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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>();
Copy link
Contributor

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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).

Copy link
Contributor

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.

Copy link
Contributor Author

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>();
Copy link
Contributor Author

@schneiml schneiml Feb 22, 2018

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?

Copy link
Contributor

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_;
Copy link
Contributor

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit says HACK in the message for a good reason. After #22218, enableMultiThread has exactly no reason for existence, but I'll delay removing it everywhere to after #22281 is resolved.

edm::EndLuminosityBlockProducer,
edm::EndRunProducer>
edm::EndRunProducer,
edm::one::SharedResources>
Copy link
Contributor

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 ?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@fwyzard
Copy link
Contributor

fwyzard commented Feb 22, 2018

I don't understand one thing: the DQMEDProducer now produces the token, and the METoEDM consumes it.
But what about the DQMEDHarvesters ?

They serve no purpose any longer, only cause confusion, and should be eradicated.
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Pull request #22307 was updated. @smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please check and sign again.

@schneiml
Copy link
Contributor Author

This is still WIP and probably does not even compile yet.

@fwyzard
Copy link
Contributor

fwyzard commented Feb 26, 2018

@schneiml , if you agree that this is superseded by #22319, could you close it ?

@schneiml
Copy link
Contributor Author

@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.

@schneiml schneiml closed this Feb 27, 2018
There might be more missing, per-lumi things, online, and multi-run harvesting. But the usual sequences run fine, now multi-threaded.
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Pull request #22307 was updated. @smuzaffar, @prebello, @Dr15Jones, @vazzolini, @kmaeshima, @kpedro88, @fabozzi, @cmsbuild, @jfernan2, @GurpreetSinghChahal, @vanbesien, @dmitrijus can you please check and sign again.

@schneiml schneiml changed the title RFC: DQM Step one migration to DQMToken RFC: DQMStore index logic rewrite Feb 27, 2018
@schneiml schneiml closed this Feb 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants