Improve thread safety of ReactNativeFeatureFlags #42870
Closed
Conversation
This file contains 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
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
739f2f1 to
9cdde53
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
Base commit: f3977af |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
9cdde53 to
a20e6bf
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
a20e6bf to
641b002
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
641b002 to
2a09a6a
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
2a09a6a to
8a7f427
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
…42870) Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
8a7f427 to
d0a8ea3
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
d0a8ea3 to
abe44a1
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
abe44a1 to
2e04cd5
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Feb 5, 2024
…42870) Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
Summary: This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety: * It makes all cached feature flags atomic to prevent data corruption when writing them concurrently. * It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector. Performance-wise, this is lock-free so it would still be fast enough for our use cases. Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed). Changelog: [internal] Reviewed By: javache Differential Revision: D53406924
rubennorte
force-pushed
the
export-D53406924
branch
from
2e04cd5 to
f9eaae4
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53406924 |
|
This pull request has been merged in fe69f71. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary:
This refactors
ReactNativeFeatureFlagsAccessorin C++ to improve its thread-safety:Performance-wise, this is lock-free so it would still be fast enough for our use cases.
Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed).
Changelog: [internal]
Differential Revision: D53406924