[SERVER-44022] Fix race in PrepareConflictTracker Created: 15/Oct/19 Updated: 29/Oct/23 Resolved: 24/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Geert Bosch | Assignee: | Geert Bosch |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Execution Team 2019-12-02, Execution Team 2019-12-30, Execution Team 2020-01-13, Execution Team 2020-01-27, Execution Team 2020-02-10, Execution Team 2019-12-30, Execution Team 2020-02-24, Execution Team 2020-03-09 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
The PrepareConflictTracker uses an atomic boolean to indicate that a client is waiting on a prepare conflict, but that does not actually protect the _prepareConflictDuration from being concurrently written to and read from. In addition to fixing this race, presumably by using another atomic variable, also make sure that the endPrepareConflict code is a no-op (and does no atomic operations) for cases where there were no prepare conflicts. This is needed because this code is executed for every storage engine level read operation and is therefore very hot, and shows up in profiling information. |
| Comments |
| Comment by Githook User [ 24/Feb/20 ] |
|
Author: {'username': 'GeertBosch', 'name': 'Geert Bosch', 'email': 'geert.bosch@mongodb.com'}Message: |