Skip to content
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

Merged

Conversation

mariusc83
Copy link
Member

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)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@mariusc83 mariusc83 self-assigned this Oct 3, 2024
@@ -31,8 +31,12 @@ internal class DataOkHttpUploader(
val androidInfoProvider: AndroidInfoProvider
) : DataUploader {

private var attempts = 1
private var attempts: Int = 1
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

@mariusc83 mariusc83 force-pushed the mconstantin/make-request-retry-information-thread-safe branch from 5f8b999 to 3f3102b Compare October 3, 2024 15:01
@mariusc83 mariusc83 marked this pull request as ready for review October 3, 2024 15:01
@mariusc83 mariusc83 requested review from a team as code owners October 3, 2024 15:01
@codecov-commenter
Copy link

codecov-commenter commented Oct 4, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.30%. Comparing base (7ebe827) to head (3f3102b).
Report is 2 commits behind head on develop.

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     
Files with missing lines Coverage Δ
...id/core/internal/data/upload/DataOkHttpUploader.kt 89.81% <100.00%> (ø)

... and 31 files with indirect coverage changes

@mariusc83 mariusc83 merged commit 9a45d07 into develop Oct 4, 2024
23 checks passed
@mariusc83 mariusc83 deleted the mconstantin/make-request-retry-information-thread-safe branch October 4, 2024 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants