-
Notifications
You must be signed in to change notification settings - Fork 64
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
Make the DataOkHttpUploader state volatile #2305
Make the DataOkHttpUploader state volatile #2305
Conversation
@@ -31,8 +31,12 @@ internal class DataOkHttpUploader( | |||
val androidInfoProvider: AndroidInfoProvider | |||
) : DataUploader { | |||
|
|||
private var attempts = 1 | |||
private var attempts: Int = 1 |
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.
why not making this one as @Volatile
or even AtomicInteger
. There is no concurrency right now (so probably AtomicInteger
is not quite useful), but for the changes at least shouldn't we declare volatile access?
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 was almost convinced that primitives are volatile in JVM. The docs are saying either true or false so let's do this also Volatile. There is no need for Atomicity there.
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.
https://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html
Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
Reads and writes are atomic for all variables declared volatile (including long and double variables).
I'm not sure about ART though, but maybe it should maintain this as well.
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.
Also atomic read/write is different from cross-thread visibility though.
When a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations. Volatile variables are not cached in registers or in caches where they are hidden from other processors, so a read of a volatile variable always returns the most recent write by any thread.
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.
Yes there are 2 different things but I am pretty sure I've read also about volatility once, anyway I guess without going into the bytecode you will never now for sure.
5f8b999
to
3f3102b
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #2305 +/- ##
===========================================
- Coverage 70.32% 70.30% -0.02%
===========================================
Files 736 736
Lines 27466 27471 +5
Branches 4607 4607
===========================================
- Hits 19315 19312 -3
+ Misses 6871 6863 -8
- Partials 1280 1296 +16
|
What does this PR do?
Initially I thought that given the fact that the
DataOkHttpUploader
is being executed sequentially there is no need for thread safety in it. After a team discussion we stumbled upon this corner case where the executor could actually kill that thread and spawn a new one therefor we need to make sure these states are Volatile and kept in the Heap.Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)