-
-
Notifications
You must be signed in to change notification settings - Fork 349
Preventing Deadlocks When Reading Metadata Concurrently via asyncio.gather
#3207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
dgegen
wants to merge
2
commits into
zarr-developers:main
Choose a base branch
from
dgegen:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+202
−29
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
- This pull request resolves the issue of deadlocks and indefinite hangs when | ||
opening Zarr v3 arrays on synchronous fsspec filesystems, by implementing a | ||
fallback to sequential reads for non-concurrency-safe filesystems, ensuring | ||
robust metadata retrieval without sacrificing performance for safe | ||
filesystems. Furthermore ``Store._get_many`` was modified to retrieve objects | ||
concurrently from storage. The previous implementation was sequential, | ||
awaiting each ``self.get(*req)`` before proceeding, contrary to the | ||
docstring. | ||
- Introduced ``StorePath.get_many``, mimicing the behaviour of `StorePath.get`. | ||
- Use ``Store._get_many`` and ``StorePath.get_many`` in ``get_array_metadata``. | ||
- Implemented ``FsspecStore._get_many`` to conditionally use ``asyncio.gather`` | ||
based on the concurrency safety of the underlying file system, enhancing | ||
compatibility with synchronous file systems by avoiding deadlocks when | ||
accessing metadata concurrently. Adding tests ``LockableFileSystem`` to test | ||
with async/sync behavior. |
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -513,19 +513,23 @@ async def open( | |
consolidated_key = use_consolidated | ||
|
||
if zarr_format == 2: | ||
paths = [store_path / ZGROUP_JSON, store_path / ZATTRS_JSON] | ||
requests = [ | ||
(key, default_buffer_prototype(), None) for key in [ZGROUP_JSON, ZATTRS_JSON] | ||
] | ||
if use_consolidated or use_consolidated is None: | ||
paths.append(store_path / consolidated_key) | ||
requests.append((consolidated_key, default_buffer_prototype(), None)) | ||
|
||
zgroup_bytes, zattrs_bytes, *rest = await asyncio.gather( | ||
*[path.get() for path in paths] | ||
retrieved_buffers = {key: value async for key, value in store_path.get_many(requests)} | ||
zgroup_bytes, zattrs_bytes = ( | ||
retrieved_buffers[ZGROUP_JSON], | ||
retrieved_buffers[ZATTRS_JSON], | ||
) | ||
|
||
if zgroup_bytes is None: | ||
raise FileNotFoundError(store_path) | ||
|
||
if use_consolidated or use_consolidated is None: | ||
maybe_consolidated_metadata_bytes = rest[0] | ||
|
||
maybe_consolidated_metadata_bytes = retrieved_buffers[consolidated_key] | ||
else: | ||
maybe_consolidated_metadata_bytes = None | ||
|
||
|
@@ -534,17 +538,18 @@ async def open( | |
if zarr_json_bytes is None: | ||
raise FileNotFoundError(store_path) | ||
elif zarr_format is None: | ||
requests = [ | ||
(key, default_buffer_prototype(), None) | ||
for key in [ZARR_JSON, ZGROUP_JSON, ZATTRS_JSON, consolidated_key] | ||
] | ||
retrieved_buffers = {key: value async for key, value in store_path.get_many(requests)} | ||
( | ||
zarr_json_bytes, | ||
zgroup_bytes, | ||
zattrs_bytes, | ||
maybe_consolidated_metadata_bytes, | ||
) = await asyncio.gather( | ||
(store_path / ZARR_JSON).get(), | ||
(store_path / ZGROUP_JSON).get(), | ||
(store_path / ZATTRS_JSON).get(), | ||
(store_path / str(consolidated_key)).get(), | ||
) | ||
) = tuple(retrieved_buffers.get(req[0]) for req in requests) | ||
|
||
if zarr_json_bytes is not None and zgroup_bytes is not None: | ||
# warn and favor v3 | ||
msg = f"Both zarr.json (Zarr format 3) and .zgroup (Zarr format 2) metadata objects exist at {store_path}. Zarr format 3 will be used." | ||
|
@@ -3476,10 +3481,14 @@ async def _read_metadata_v2(store: Store, path: str) -> ArrayV2Metadata | GroupM | |
""" | ||
# TODO: consider first fetching array metadata, and only fetching group metadata when we don't | ||
# find an array | ||
zarray_bytes, zgroup_bytes, zattrs_bytes = await asyncio.gather( | ||
store.get(_join_paths([path, ZARRAY_JSON]), prototype=default_buffer_prototype()), | ||
store.get(_join_paths([path, ZGROUP_JSON]), prototype=default_buffer_prototype()), | ||
store.get(_join_paths([path, ZATTRS_JSON]), prototype=default_buffer_prototype()), | ||
requests = [ | ||
(_join_paths([path, ZARRAY_JSON]), default_buffer_prototype(), None), | ||
(_join_paths([path, ZGROUP_JSON]), default_buffer_prototype(), None), | ||
(_join_paths([path, ZATTRS_JSON]), default_buffer_prototype(), None), | ||
Comment on lines
+3485
to
+3487
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. lets bind
|
||
] | ||
retrieved_buffers = {key: value async for key, value in store._get_many(requests)} | ||
zarray_bytes, zgroup_bytes, zattrs_bytes = tuple( | ||
retrieved_buffers.get(req[0]) for req in requests | ||
) | ||
|
||
if zattrs_bytes is None: | ||
|
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the advantage of this new implementation? the previous implementation was extremely simple, which I think is good for an abc.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The claim in the docstring is incorrect given the previous implementation.
This loop is sequential: it awaits each self.get(*req) and yields it before moving on to the next. Each request is handled one at a time, in the exact order provided. Therefore, results are always yielded in the same order as the input requests.
It is thus not fully concurrent which would be desirable in an I/O-limited system and, at least as I understand, kind of defeats the purpose of having an asynchronous
_get_many
method yielding results in the first place. Because if we stick to the order, we might as well await all results and simply replace the implementation of_get_many
with that of_get_many_ordered
, making it faster and arguable more easy to used in the asynchronous case. If we want to give the extra flexibility of not awaiting all at once, but still requesting all at the same time, the new implementation would be the right one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the point of the default implementation is to be the simplest possible implementation of
_get_many
that any child class can safely support, given an implementation ofget
. But child classes should also be able to override this with more efficient methods where applicable, and in these cases the order of results is not guaranteed. hence the type annotation in the original method.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this somewhat confusing, as I would have expected the standard implementation to be fully asynchronous. However, if the goal is to maximize simplicity, then having an asynchronous implementation that runs synchronously might be the way to go.
That being said, if we revert this to the original, we would only have to also remove the
FsspecStore._get_many
from my current solution. Unless you think we should not have a_get_many_ordered
method and use the_get_many
method instead and then always sort the values locally, as they could be of a different order in other implementations.