This repository was archived by the owner on Feb 6, 2026. It is now read-only.
fix(dal): : synchronize graph access in dependent values updates#3488
Merged
si-bors-ng[bot] merged 1 commit intomainfrom Mar 29, 2024
Merged
fix(dal): : synchronize graph access in dependent values updates#3488si-bors-ng[bot] merged 1 commit intomainfrom
si-bors-ng[bot] merged 1 commit intomainfrom
Conversation
The concurrency types used by the WorkspaceSnapshot to provide interior mutability in the tokio run time are *not* sufficient to prevent data races when operating on the same graph on different threads, since our graph operations are not "atomic" and the graph *WILL* end up being read from different threads while a write operation is still in progress if it is shared between threads for modification. For example after a node is added but *before* the edges necessary to place that node in the right spot in the graph. A more general solution is needed to represent the concept of a "transaction" when mutating the graph, to prevent other readers from seeing incomplete graphs from in-progress write operations. For now, we have added a lock to `DependentValuesUpdate` that ensures the portion of the update that gathers the inputs to a function acquires a read lock, (which is released as soon as the function is sent to the executor, so that we don't hold on to it while executing in veritech), while the portion of the update that updates the graph with the execution result acquires a write lock. Co-Authored-By: Jacob Helwig <jacob@systeminit.com> Co-Authored-By: Nick Gerace <nick@systeminit.com> Co-Authored-By: Scott Prutton <scott@systeminit.com>
8210f8b to
21813a7
Compare
Contributor
Author
|
bors r+ |
Contributor
|
Build succeeded: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The concurrency types used by the WorkspaceSnapshot to provide interior mutability in the tokio run time are not sufficient to prevent data races when operating on the same graph on different threads, since our graph operations are not "atomic" and the graph WILL end up being read from different threads while a write operation is still in progress if it is shared between threads for modification. For example after a node is added but before the edges necessary to place that node in the right spot in the graph.
A more general solution is needed to represent the concept of a "transaction" when mutating the graph, to prevent other readers from seeing incomplete graphs from in-progress write operations.
For now, we have added a lock to
DependentValuesUpdatethat ensures the portion of the update that gathers the inputs to a function acquires a read lock, (which is released as soon as the function is sent to the executor, so that we don't hold on to it while executing in veritech), while the portion of the update that updates the graph with the execution result acquires a write lock.