Avoid unnecessary Framework delays closing luminosity blocks (simple version)

FWCore/Framework/src/EventProcessor.cc

@@ -2212,6 +2212,10 @@ namespace edm {
   }
 
   void EventProcessor::handleNextEventForStreamAsync(WaitingTaskHolder iTask, unsigned int iStreamIndex) {
+    if (streamLumiStatus_[iStreamIndex]->haveStartedNextLumiOrEndedRun()) {
+      streamEndLumiAsync(iTask, iStreamIndex);
+      return;
+    }
     auto group = iTask.group();
     sourceResourcesAcquirer_.serialQueueChain().push(*group, [this, iTask = std::move(iTask), iStreamIndex]() mutable {
       CMS_SA_ALLOW try {

FWCore/Framework/src/LuminosityBlockProcessingStatus.h

@@ -87,8 +87,8 @@ namespace edm {
     EventProcessingState eventProcessingState() const { return eventProcessingState_; }
     void setEventProcessingState(EventProcessingState val) { eventProcessingState_ = val; }
 
-    bool haveStartedNextLumiOrEndedRun() const { return startedNextLumiOrEndedRun_; }
-    void startNextLumiOrEndRun() { startedNextLumiOrEndedRun_ = true; }
+    bool haveStartedNextLumiOrEndedRun() const { return startedNextLumiOrEndedRun_.load(); }
+    void startNextLumiOrEndRun() { startedNextLumiOrEndedRun_.store(true); }
 
     bool didGlobalBeginSucceed() const { return globalBeginSucceeded_; }
     void globalBeginDidSucceed() { globalBeginSucceeded_ = true; }
@@ -107,7 +107,7 @@ namespace edm {
     edm::Timestamp endTime_{};
     std::atomic<char> endTimeSetStatus_{0};
     EventProcessingState eventProcessingState_{EventProcessingState::kProcessing};
-    bool startedNextLumiOrEndedRun_{false};  //read/write in m_sourceQueue
+    std::atomic<bool> startedNextLumiOrEndedRun_{false};
     bool globalBeginSucceeded_{false};
     bool cleaningUpAfterException_{false};
   };

FWCore/Integration/test/testLateLumiClosure_cfg.py

@@ -1,3 +1,20 @@
+# This test originally demonstrated a problem
+# reported online. The problem has since been
+# fixed by a modification in the function
+# EventProcessor::handleNextEventForStreamAsync.
+# I've left unmodified a description of the
+# problem below. It is still interesting to keep
+# this configuration around and running as it
+# still demonstrates the circumstances in a
+# way that none of the other tests replicate
+# and shows that the problem is fixed if one
+# examines the log output. Note that it is not
+# coded as a pass/fail test because the timing
+# could vary and we don't want a test that
+# occasionally fails. It might sometimes still
+# exhibit the problem behavior if for example
+# a thread hangs.
+
 # Demonstrates a problem first noticed online. Say there
 # are 3 lumis. The first and last lumis have events.
 # The middle one has no events. We are using