[SERVER-72918] Fix theoretical data race in transaction API test Created: 17/Jan/23  Updated: 29/Oct/23  Resolved: 18/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0-rc0

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding NYC 2023-01-23
Participants:
Linked BF Score: 63

 Description   

Transaction API unit test DoesNotWaitForBestEffortAbortIfCancelled accesses an unsynchronized member variable in the test's mocked transaction API client, which triggered a TSAN failure. The access happens when the transaction API using the mocked client should be blocked on a condition variable, so there shouldn't be a problem in practice, but we should add synchronization to the mock class to silence TSAN and follow best concurrency practices.



 Comments   
Comment by Githook User [ 18/Jan/23 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-72918 Use mutex and barrier in MockTransactionClient
Branch: master
https://github.com/mongodb/mongo/commit/4419a88f35d73f594a0b91e7ee68467d38152671

Comment by Jack Mulrow [ 17/Jan/23 ]

On closer look, I realized some tests don't guarantee the best effort abort has run when they expect that, so I'll also fix that in this ticket.

Generated at Thu Feb 08 06:23:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.