Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(storage-manager): race condition on
latest_updates
structure
As the lock on the `latest_updates` structure was dropped before the operation on the Storage was performed and re-acquired afterwards, a race condition could have happened as illustrated in the following scenario. --- Let us assume that the Storage and `latest_updates` have `(A, T_A0)`. A first operation is performed with `T_A1 > T_A0`. As the timestamp is greater, `latest_updates` will allow it. The lock on `latest_updates` is released. The Storage is updated and has `(A, T_A1)`. In the meantime, another operation is received with `T_A2 > T_A0`. As the timestamp is greater than `T_A0` (`latest_updates` was still not updated!), it is allowed. For scheduling reasons, the second operation is performed *entirely*: the Storage and `latest_updates` both have `(A, T_A2)`. The scheduler goes back to finish `T_A1` and inserts in `latest_updates` the pair `(A, T_A1)`. The information in the Storage (`(A, T_A2)`) and in `latest_updates` (`(A, T_A1)`) are no longer coherent. --- This commit fixes this issue by only releasing the lock on the `latest_updates` structure after having updated it — instead of after checking if the received operation is more recent. Note that this should create very little additional contention: the bulk of the processing is performed when interacting with the Storage, not when checking / updating the `latest_updates` structure. * plugins/zenoh-plugin-storage-manager/src/replica/storage.rs: only release the lock on the `latest_updates` structure after having updated it. Signed-off-by: Julien Loudet <[email protected]>
- Loading branch information