Avoid deadlock by taking SharedResource lock first #9483
Conversation
Tests running unscheduled workflows found a deadlock do to a legacy module doing an unscheduled get from another legacy module while another thread was trying to run the second legacy module. This caused the order of locks (module lock then legacy lock) to be changed for the second module which lead to the deadlock. This change is a temporary workaround in which we take the legacy lock before the module lock. This work most of the time but still can cause a deadlock for the case of two 'one' modules both with different shared resources but one of them calling a legacy module (which tries to take locks to all resources). A complete fix is forth coming.
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_7_4_X. Avoid deadlock by taking SharedResource lock first It involves the following packages: FWCore/Framework @cmsbuild, @Dr15Jones can you please review it and eventually sign? Thanks. |
|
please test |
|
+1 |
|
The tests are being triggered in jenkins. |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs unless changes or unless it breaks tests. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs unless changes or unless it breaks tests. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs unless changes (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar |
|
+1 |
…sourceLockFirst Avoid deadlock by taking SharedResource lock first
Tests running unscheduled workflows found a deadlock do to a legacy
module doing an unscheduled get from another legacy module while another
thread was trying to run the second legacy module. This caused the order
of locks (module lock then legacy lock) to be changed for the second
module which lead to the deadlock.
This change is a temporary workaround in which we take the legacy lock
before the module lock. This work most of the time but still can cause
a deadlock for the case of two 'one' modules both with different shared
resources but one of them calling a legacy module (which tries to take
locks to all resources). A complete fix is forth coming.