You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem spotted in GATK due to smelly use and no use of synchronized in CRAM ReferenceSource: broadinstitute/gatk#8139
.../cram/.../ReferenceSource.java has a mixture of synchronized and non-synchronzed access to its cache member fields that results in a race condition when accessing it in parallel by at least one tool in GATK.
This class already contain synchronized modifier which implies that is supposed to support multi-thread access.
Your environment:
version of htsjdk
Current master:9f0e80f5bf
version of java
Not relevant
which OS
Not relevant
Steps to reproduce
See original post. No concrete test input data provided but the problem becomes clear when inspecting the code.
Expected behaviour
Either
(a) this class is made multithread safe or
(b) it clearly stated that is not multi-thread safe and the multithread elements (e.g. synchronized modifiers) are removed.
Actual behaviour
At least there is one way to cause race conditions in multi-thread use of this class. There could be more, so code should be review for other possible issues.
The text was updated successfully, but these errors were encountered:
…t might be trying to solve an non-existent issue.
Chaned WeakReference to SoftReference to make cache more persistent in memory.
Addresses issue #1643.
Description of the issue:
Problem spotted in GATK due to smelly use and no use of synchronized in CRAM ReferenceSource:
broadinstitute/gatk#8139
.../cram/.../ReferenceSource.java has a mixture of synchronized and non-synchronzed access to its cache member fields that results in a race condition when accessing it in parallel by at least one tool in GATK.
This class already contain synchronized modifier which implies that is supposed to support multi-thread access.
Your environment:
Current master:9f0e80f5bf
Not relevant
Not relevant
Steps to reproduce
See original post. No concrete test input data provided but the problem becomes clear when inspecting the code.
Expected behaviour
Either
(a) this class is made multithread safe or
(b) it clearly stated that is not multi-thread safe and the multithread elements (e.g. synchronized modifiers) are removed.
Actual behaviour
At least there is one way to cause race conditions in multi-thread use of this class. There could be more, so code should be review for other possible issues.
The text was updated successfully, but these errors were encountered: