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

Issue 5664: (SLTS) fix possible thread visibility issues.. #5665

Merged

Conversation

sachin-j-joshi
Copy link
Contributor

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

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>

# Conflicts:
#	segmentstore/storage/src/main/java/io/pravega/segmentstore/storage/chunklayer/ReadOperation.java
@codecov
Copy link

codecov bot commented Feb 6, 2021

Codecov Report

Merging #5665 (2f5fcc4) into master (5dc1c7e) will increase coverage by 0.04%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             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     
Impacted Files Coverage Δ Complexity Δ
...tore/storage/chunklayer/ChunkedSegmentStorage.java 89.64% <ø> (ø) 109.00 <0.00> (ø)
...a/segmentstore/storage/metadata/ChunkMetadata.java 100.00% <ø> (ø) 8.00 <0.00> (ø)
...segmentstore/storage/metadata/SegmentMetadata.java 75.80% <ø> (+0.80%) 17.00 <0.00> (-2.00) ⬆️
...gmentstore/storage/chunklayer/ConcatOperation.java 91.91% <100.00%> (ø) 28.00 <1.00> (ø)
...tstore/storage/chunklayer/DefragmentOperation.java 96.06% <100.00%> (ø) 45.00 <1.00> (ø)
...segmentstore/storage/chunklayer/SystemJournal.java 93.50% <100.00%> (ø) 50.00 <0.00> (ø)
...entstore/storage/chunklayer/TruncateOperation.java 93.75% <100.00%> (ø) 33.00 <1.00> (ø)
...egmentstore/storage/chunklayer/WriteOperation.java 94.97% <100.00%> (ø) 63.00 <1.00> (ø)
...pravega/client/connection/impl/CommandEncoder.java 87.71% <0.00%> (-1.76%) 33.00% <0.00%> (ø%)
...ntstore/server/host/ZKSegmentContainerMonitor.java 80.67% <0.00%> (-1.69%) 26.00% <0.00%> (ø%)
... and 19 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5dc1c7e...2f5fcc4. Read the comment docs.

Copy link
Member

@andreipaduroiu andreipaduroiu left a 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).

@sachin-j-joshi
Copy link
Contributor Author

The code does not modify any lists concurrently. The code is just series of lambdas that are executed one after another via CompletableFuture.then... chaining. So I think its is safe in that sense.

This change fixes possible thread visibility issues as execution may jump from one core to another.

@sachin-j-joshi sachin-j-joshi changed the title Issue 5664: SLTS - fix possible thread visibility issues.. Issue 5664: (SLTS) fix possible thread visibility issues.. Feb 8, 2021
@andreipaduroiu andreipaduroiu merged commit caf1314 into pravega:master Feb 8, 2021
tkaitchuck pushed a commit to tkaitchuck/pravega-1 that referenced this pull request Feb 15, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
tkaitchuck pushed a commit to tkaitchuck/pravega-1 that referenced this pull request Feb 15, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
co-jo pushed a commit to co-jo/pravega that referenced this pull request Feb 16, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
sachin-j-joshi added a commit to sachin-j-joshi/pravega that referenced this pull request Feb 23, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
co-jo pushed a commit to co-jo/pravega that referenced this pull request Mar 1, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
co-jo pushed a commit to co-jo/pravega that referenced this pull request Mar 9, 2021
)

Use Collections.synchronized /synchronized to force memory barrier.
Use volatile for mutable variables.

Signed-off-by: Sachin Joshi <sachin.joshi@emc.com>
sachin-j-joshi added a commit that referenced this pull request Mar 19, 2021
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>
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.

SLTS - fix possible thread visibility issues.
2 participants