-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code
-
None
-
Fully Compatible
-
ALL
-
-
Quint Iteration 3.1.2
-
None
-
None
-
None
-
None
-
None
-
None
-
None
When migratePartitionedLockHeads() calls newRequest(), it can write to member variables (LockRequest::mode, LockRequest::status) that are owned by another thread with no synchronization. This is benign because the values written are guaranteed to be the same as the preexisting values, by the code logic. However, this still trips a data race error from the thread sanitizer.
Kal recommends that we write a new function to supplement newRequest() that includes only the logic that is necessary for migratePartitionedLockHeads().