[SERVER-40085] Avoid using barriers in TimestampMonitorNotifiesListeners to avoid deadlock in test Created: 12/Mar/19  Updated: 29/Oct/23  Resolved: 13/Mar/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.9

Type: Bug Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2019-03-25
Participants:
Linked BF Score: 13

 Description   

We should change the usage of barriers in `TimestampMonitorNotifiesListeners` to use a mutex and condition variable instead. Using barriers in this test can lead to a deadlock scenario.

For example, while the first thread is adding listeners, the timestamp monitor in the second thread can start notifying listeners that were already added by the first thread. While this happens, the timestamp monitor holds its own mutex and waits for the barrier in the test. This prevents the first thread from continuing to add listeners as it needs to grab the timestamp monitors mutex. The deadlock occurs here as the first thread will never hit the barrier that the second thread is waiting for.



 Comments   
Comment by Githook User [ 13/Mar/19 ]

Author:

{'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}

Message: SERVER-40085 Avoid using barriers in TimestampMonitorNotifiesListeners
Branch: master
https://github.com/mongodb/mongo/commit/422e304a2b3514c1b3f8f3dd452fcd5fc598b51f

Generated at Thu Feb 08 04:53:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.