-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Fixed potential torn reads in EventCounters #22923
Conversation
The backing fields for the counters are `long`, so there was potential torn read on 32-bit platforms. `Volatile.Read` ensures that the value is read in a atomic way, so no torn reads can occur.
See ongoing conversation in npgsql/npgsql#3223 (comment) |
Updated to use |
Too eagerly with find & replace -- sorry.
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.
Thanks!
There's also a Volatile.Read and Volatile.Write in CalculateAndReset below - these should actually be a single Interlocked.Exchange operation (set to 0 and get the previous value out). Any chance you can do that as part of this PR?
Of course 😃 --> 2d39eb9 |
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.
Thanks!
@dotnet/efteam Should we take this in 5.0? |
I'm not sure this qualifies... It only affects 32-bit systems (really rare nowadays), and even there is really non-fatal. On the flip-side, the risk here is extremely low. |
Let's discuss in triage. |
The backing fields for the counters are
long
, so there was potential torn read on 32-bit platforms.Volatile.Read
ensures that the value is read in a atomic way, so no torn reads can occur.