Fix Swap and CompareAndSwap for Value wrappers #130
Merged
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
Fixes #126, #129 All atomic types can be used without initialization, e.g., `var v <AtomicType>`. This works fine for integer types as the initialized value of 0 matches the default value for the user-facing type. However, for Value wrappers, they are initialized to `nil`, which is a value that can't be set (triggers a panic) so the default value for the user-facing type is forced to be stored as a different value. This leads to multiple possible values representing the default user-facing type. E.g., an `atomic.String` with value `""` may be represented by the underlying atomic as either `nil`, or `""`. This causes issues when we don't handle the `nil` value correctly, causing to panics in `Swap` and incorrectly not swapping values in `CompareAndSwap`. This change fixes the above issues by: * Requiring `pack` and `unpack` function in gen-atomicwrapper as the only place we weren't supplying them was for `String`, and the branching adds unnecessary complexity, especially with added `nil` handling. * Extending `CompareAndSwap` for `Value` wrappers to try an additional `CompareAndSwap(nil, <new>)` only if the original `CompareAndSwap` fails and the old value is the zero value.
Codecov Report
@@ Coverage Diff @@
## master #130 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 23 23
Lines 232 242 +10
=========================================
+ Hits 232 242 +10
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
sywhang
approved these changes
Feb 6, 2023
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.
Fixes #126, #129
All atomic types can be used without initialization, e.g.,
var v <AtomicType>. This works fine for integer types as the initializedvalue of 0 matches the default value for the user-facing type. However,
for Value wrappers, they are initialized to
nil, which is a value thatcan't be set (triggers a panic) so the default value for the user-facing
type is forced to be stored as a different value. This leads to multiple
possible values representing the default user-facing type.
E.g., an
atomic.Stringwith value""may be represented by theunderlying atomic as either
nil, or"". This causes issues when wedon't handle the
nilvalue correctly, causing to panics inSwapandincorrectly not swapping values in
CompareAndSwap.This change fixes the above issues by:
packandunpackfunction in gen-atomicwrapper as theonly place we weren't supplying them was for
String, and thebranching adds unnecessary complexity, especially with added
nilhandling.
CompareAndSwapforValuewrappers to try an additionalCompareAndSwap(nil, <new>)only if the originalCompareAndSwapfails and the old value is the zero value.
This change is reviewable by commit.