Use optimistic synchronization in JsonWebToken.Audiences #2243
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
I didn't see anything in Payload.TryGetValue that would require synchronization with a concurrent call to Payload.TryGetValue. And without that, and since concurrent access is not something to optimize for here, we can instead employ optimistic synchronization and just swap in the result with an interlocked. If there's a race condition and two threads do end up accessing Audiences on the same instance concurrently, they may both end up creating the array, but only one will be published for all to consume. In addition to making Audiences cheaper to access, the primary benefit here is it saves an allocation per JsonWebToken, which no longer needs to construct the audiences lock object.
westin-m
approved these changes
Aug 22, 2023
brentschmaltz
approved these changes
Aug 22, 2023
|
Included in preview4 release |
brentschmaltz
pushed a commit
that referenced
this pull request
Sep 6, 2023
I didn't see anything in Payload.TryGetValue that would require synchronization with a concurrent call to Payload.TryGetValue. And without that, and since concurrent access is not something to optimize for here, we can instead employ optimistic synchronization and just swap in the result with an interlocked. If there's a race condition and two threads do end up accessing Audiences on the same instance concurrently, they may both end up creating the array, but only one will be published for all to consume. In addition to making Audiences cheaper to access, the primary benefit here is it saves an allocation per JsonWebToken, which no longer needs to construct the audiences lock object.
brentschmaltz
pushed a commit
that referenced
this pull request
Sep 7, 2023
I didn't see anything in Payload.TryGetValue that would require synchronization with a concurrent call to Payload.TryGetValue. And without that, and since concurrent access is not something to optimize for here, we can instead employ optimistic synchronization and just swap in the result with an interlocked. If there's a race condition and two threads do end up accessing Audiences on the same instance concurrently, they may both end up creating the array, but only one will be published for all to consume. In addition to making Audiences cheaper to access, the primary benefit here is it saves an allocation per JsonWebToken, which no longer needs to construct the audiences lock object.
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.
I didn't see anything in Payload.TryGetValue that would require synchronization with a concurrent call to Payload.TryGetValue. And without that, and since concurrent access is not something to optimize for here, we can instead employ optimistic synchronization and just swap in the result with an interlocked. If there's a race condition and two threads do end up accessing Audiences on the same instance concurrently, they may both end up creating the array, but only one will be published for all to consume.
In addition to making Audiences cheaper to access, the primary benefit here is it saves an allocation per JsonWebToken, which no longer needs to construct the audiences lock object.