-
Notifications
You must be signed in to change notification settings - Fork 406
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
Issue 5664: (SLTS) fix possible thread visibility issues.. #5665
Issue 5664: (SLTS) fix possible thread visibility issues.. #5665
Conversation
Signed-off-by: Sachin Joshi <sachin.joshi@emc.com> # Conflicts: # segmentstore/storage/src/main/java/io/pravega/segmentstore/storage/chunklayer/ReadOperation.java
Codecov Report
@@ Coverage Diff @@
## master #5665 +/- ##
============================================
+ Coverage 84.73% 84.78% +0.04%
- Complexity 13883 13891 +8
============================================
Files 917 917
Lines 51440 51434 -6
Branches 5307 5305 -2
============================================
+ Hits 43587 43606 +19
+ Misses 4956 4942 -14
+ Partials 2897 2886 -11
Continue to review full report at Codecov.
|
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.
This looks good. Thanks for doing it.
One comment before I approve it. Even though a Collection may be synchronized, if you iterate through it (using iterator
), that is not thread safe and it will still throw a ConcurrentModificationException
if you modify it while some other thread iterates through it.
I can't tell from this PR whether this is the case here, but would you mind checking the code you modified for places where these are accessed to ensure they are not iterated over.
If you need iteration, your best bet is to encapsulate them and make a copy every time you need an iterator (so iterate over the copy).
The code does not modify any lists concurrently. The code is just series of lambdas that are executed one after another via This change fixes possible thread visibility issues as execution may jump from one core to another. |
Cherry-picks following changes 0.9 Issue 5518: (SLTS) Fix Integer overflow. (#5520) Issue 5606: BoundedInputStream::markSupported() should always return false.. (#5615) Issue 5597 : ExtendedS3ChunkStorage and ExtendedS3Storage should close S3Client. (#5598) Issue 5535: (SegmentStore) Refactoring ExtendedS3 Test Mocks (#5537) Issue 5456: (SLTS) - Handle possible failure during deletion of metadata keys can cause version mismatch in next attempt (#5457) Issue 5458: (SLTS) For read operation, read all chunks in parallel. (#5459) Issue 4967: (SLTS) Add createWithContent overload that creates object and writes to it in a single call. (#5455) Issue 5664: SLTS - fix possible thread visibility issues.. (#5665) Issue 5475: Eliminate unnecessary pessimistic checks. (#5662) Issue 5570: (SLTS) AsyncBaseChunkStorage latency should not include time spent in waiting to be executed. (#5661) Issue 4967: (SLTS) No need to check last chunk length for claimOwnership for no append mode. (#5663) Issue 5673: (SLTS) Fix wrong GC config (#5674) Issue 5737: (SLTS) Improve metrics (#5746) Issue 5460: (SLTS) Add read index virtual block entries to metadata. (#5461) Issue 5772: (SLTS) - BaseMetadataStore does not evict entries from buffer. (#5773) Issue 5798: (SLTS) Fix close in GarbageCollector, ExtendedS3ChunkStorage and HDFSChunkStorage. (#5800) Issue 5788: (SLTS) Remove ACL operations from ExtendedS3ChunkStorage (#5790) Issue 5808: SLTS - Fix Preconditions checks to include enough information in message. (#5809) Issue 5853: SLTS - BaseMetadataStore.get does not return deep copy when loading from store. #5858 Issue 5866: (SLTS) ReadIndexCache stats not reported. (#5867) Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
Signed-off-by: Sachin Joshi sachin.joshi@emc.com
Change log description
Use Collections.synchronized /synchronized to force memory barrier
Use volatile for mutable variables
Purpose of the change
Fixes #5664
What the code does
There are couple of places in SLTS code where arrays and other data structures are protected from concurrent modifications yet could still potentially show thread visibility issue.
How to verify it
Use Collections.synchronized /synchronized to force memory barrier
Use volatile for mutable variables