Info

Threads may try to acquire two locks in different orders, potentially causing deadlock Defect 100779 (STATIC_C) Checker ORDER_REVERSAL (subcategory none) File: /src/mongo/db/logical_clock.cpp Function mongo::LogicalClock::reserveTicks(unsigned long)

Top User Comments

sheeri.cabral commented on Thu, 2 Jan 2020 14:30:45 +0000: This is a valid bug but the mock is used in single-threaded unit tests, and not seen in the wild or in testing. misha.tyulenev commented on Tue, 21 Nov 2017 21:10:06 +0000: Moving to Backlog as this is an issue that is not possible for production code because the BackgroundThreadClockSource::now() does not use mutexes its an atomic. The suggested fix should change the ClockSourceMock::_now to an atomic implementation so it will not need mutexes. spencer commented on Wed, 12 Jul 2017 20:40:20 +0000: Assigning to sharding team since this involves the LogicalClock william.schultz commented on Thu, 6 Jul 2017 16:40:53 +0000: The issue Coverity picked up on has to deal with inconsistent lock acquisition order, involving the LogicalClock::_mutex and the NetworkInterfaceMock::_mutex, leading to a potential deadlock. Consider the following two functions, and the order that they acquire locks: LogicalClock::reserveTicks Acquire LogicalClock::_mutex (code ) Acquire NetworkInterfaceMock::_mutex (code ) NetworkInterfaceMock::_scheduleResponse Acquire NetworkInterfaceMock::_mutex (code ) Acquire LogicalClock::_mutex (code , readReplyFromMetadata ) Since these two functions acquire the same two locks but in reverse orders, it creates the potential for a deadlock, if each of these functions are running on separate threads and try to acquire the locks with a specific thread interleaving. I presume that the NetworkInterfaceMock would only be used for testing, and so is not a serious issue.

Steps to Reproduce