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

migrate modules used by the HLT menu to multithreading (various) #10958

Merged

Conversation

fwyzard
Copy link
Contributor

@fwyzard fwyzard commented Aug 26, 2015

This is the part of #10909 that affects more than one group.

I'm still working on it, to see if there is a more efficient solution.

  - L1GtVhdlWriterCore: get rid of an unnecessary const_cast
  - L1GtTriggerMenuXmlParser: fix the input parameter of strtol
@cmsbuild
Copy link
Contributor

A new Pull Request was created by @fwyzard (Andrea Bocci) for CMSSW_7_6_X.

migrate to modules used by the HLT menu multithreading (part 1)

It involves the following packages:

HLTrigger/HLTcore
HLTrigger/HLTfilters
L1Trigger/GlobalTrigger
L1TriggerConfig/L1GtConfigProducers

@Martin-Grunewald, @perrotta, @cmsbuild, @mulhearn, @fwyzard can you please review it and eventually sign? Thanks.
@Martin-Grunewald 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.

@@ -224,7 +223,7 @@ class Data {

// l1 values and status
const L1GlobalTriggerReadoutRecord * m_l1tResults;
const L1GtTriggerMenu * m_l1tMenu;
std::unique_ptr<L1GtTriggerMenu> m_l1tMenu;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be std::unique_ptr<const L1GtTriggerMenu>?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see it can't because of the call to buildGtConditionMap. Would it be possible to change L1GtTriggerMenu to have a constructor which calls that function?

Copy link
Contributor

Choose a reason for hiding this comment

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

I just checked the code for L1GtTriggerMenu and the copy constructor does call buildGtConditionMap so you don't have to.

@Dr15Jones
Copy link
Contributor

@fwyzard I believe I have the proper solution to your L1GtTriggerMenu problem. At the moment, when reading back a L1GtTriggerMenu from the database, one of the member data is not initialized because that member data is marked as transient:
http://cmslxr.fnal.gov/source/CondFormats/L1TObjects/src/classes_def.xml?v=CMSSW_7_6_X_2015-08-25-2300#0221

This is why people were calling buildGtConditionMap which is not thread safe to do on the product stored in the EventSetup. However, there is a mechanism to 'kick' an object right after it has been read back from the database. We can use this mechanism to call buildGtConditionMap after the object has been read from the DB but before the object is put into the EventSetup.

The trick is to use an 'Initializer' for the DataProxy
http://cmslxr.fnal.gov/source/CondCore/ESSources/interface/DataProxy.h?v=CMSSW_7_6_X_2015-08-25-2300#0039

I think the following should work:
replace
http://cmslxr.fnal.gov/source/CondCore/L1TPlugins/src/plugin.cc?v=CMSSW_7_6_X_2015-08-25-2300#0185

with

namespace cond {
   struct L1GtTriggerMenuInitializer {
      void operator()( L1GtTriggerMenu& iMenu) const {
         iMenu. buildGtConditionMap();
      }
  };
}

REGISTER_PLUGIN_INIT(L1GtTriggerMenuRcd, L1GtTriggerMenu, cond::L1GtTriggerMenuInitializer);

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 26, 2015 via email

@Dr15Jones
Copy link
Contributor

CMSSW_7_6 now uses the C++14 flags for the compiler.

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 27, 2015

hi Chris,
do you know why this works:

namespace {
  struct L1GtTriggerMenuInitializer { void operator()(L1GtTriggerMenu & _) { _.buildGtConditionMap(); } };
}
REGISTER_PLUGIN_INIT(L1GtTriggerMenuRcd, L1GtTriggerMenu, L1GtTriggerMenuInitializer);

while this does not:

REGISTER_PLUGIN_INIT(L1GtTriggerMenuRcd, L1GtTriggerMenu, [](L1GtTriggerMenu & _){ _.buildGtConditionMap(); });

and neither does:

REGISTER_PLUGIN_INIT(L1GtTriggerMenuRcd, L1GtTriggerMenu, std::mem_fn(& L1GtTriggerMenu::buildGtConditionMap));

?

@cmsbuild
Copy link
Contributor

Pull request #10958 was updated. @perrotta, @cmsbuild, @danduggan, @monttj, @Martin-Grunewald, @deguio, @fwyzard, @ggovi, @vadler, @mulhearn can you please check and sign again.

@fwyzard fwyzard force-pushed the migrate_to_multithreading_75x_part1 branch from 978abf1 to dca8ada Compare August 27, 2015 07:41
L1GtTriggerMenu is now properly initialised by the EventSetup framework,
so there is no longer need to call

  (const_cast<L1GtTriggerMenu *>(l1GtTriggerMenu))->buildGtConditionMap();

or to keep a local copy for that purpose
  - change most configuration parameters into const members
  - change into a stream::EDProducer
@fwyzard fwyzard force-pushed the migrate_to_multithreading_75x_part1 branch from e513792 to 80fa995 Compare August 27, 2015 07:46
@cmsbuild
Copy link
Contributor

Pull request #10958 was updated. @perrotta, @cmsbuild, @danduggan, @monttj, @Martin-Grunewald, @deguio, @fwyzard, @ggovi, @vadler, @mulhearn can you please check and sign again.

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 27, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 27, 2015

+1

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 27, 2015

tracked at #10964

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@Dr15Jones
Copy link
Contributor

You asked about why certain alternate forms of REGISTER_PLUGIN_INIT do not work. Ultimately the third argument of REGISTER_PLUGIN_INIT is a type passed as a template argument. The two expressions (one lambda one std::mem_fn) are not types.

@fwyzard
Copy link
Contributor Author

fwyzard commented Aug 27, 2015

You asked about why certain alternate forms of REGISTER_PLUGIN_INIT do
not work. Ultimately the third argument of REGISTER_PLUGIN_INIT is a type
passed as a template argument. The two expressions (one lambda one
std::mem_fn) are not types.

Right. Understood, thanks.

@fwyzard fwyzard changed the title migrate to modules used by the HLT menu multithreading (part 1) migrate to modules used by the HLT menu multithreading (various) Aug 30, 2015
@mulhearn
Copy link
Contributor

mulhearn commented Sep 1, 2015

+1

@deguio
Copy link
Contributor

deguio commented Sep 1, 2015

+1

@ggovi
Copy link
Contributor

ggovi commented Sep 1, 2015

+1

davidlange6 added a commit that referenced this pull request Sep 1, 2015
…part1

migrate to modules used by the HLT menu multithreading (various)
@davidlange6 davidlange6 merged commit 0ebdd65 into cms-sw:CMSSW_7_6_X Sep 1, 2015
@fwyzard fwyzard changed the title migrate to modules used by the HLT menu multithreading (various) migrate modules used by the HLT menu to multithreading (various) Sep 4, 2015
@fwyzard fwyzard deleted the migrate_to_multithreading_75x_part1 branch September 23, 2015 19:58
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

7 participants