Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-53434

Fix cleanup of ThreadPool in ReshardingOplogApplierTest unit test fixture

    XMLWordPrintableJSON

Details

    • Fully Compatible
    • Sharding 2020-12-28
    • 45
    • 1

    Description

      ReshardingOplogApplierTest fixture's way of shutting down ThreadPool inexplicably throws a std::exception (EDEADLK) when attempting to reacquire _mutex after having successfully joined all of the threads. As another way of illustrating this issue, the second of the invariants in the diff below fails sometimes when ReshardingOplogApplierTest::tearDown() is called.

      diff --git a/src/mongo/util/concurrency/thread_pool.cpp b/src/mongo/util/concurrency/thread_pool.cpp
      index d333a82d12..b115b33033 100644
      --- a/src/mongo/util/concurrency/thread_pool.cpp
      +++ b/src/mongo/util/concurrency/thread_pool.cpp
      @@ -307,9 +307,11 @@ void ThreadPool::Impl::_join_inlock(stdx::unique_lock<Latch>* lk) {
           _joinRetired_inlock();
           auto threadsToJoin = std::exchange(_threads, {});
           lk->unlock();
      +    invariant(!lk->owns_lock());
           for (auto& t : threadsToJoin) {
               t.join();
           }
      +    invariant(!lk->owns_lock());
           lk->lock();
           invariant(_state == joining);
           _setState_inlock(shutdownComplete);
      

      Attachments

        Issue Links

          Activity

            People

              max.hirschhorn@mongodb.com Max Hirschhorn
              max.hirschhorn@mongodb.com Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: