.../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.
Description of the issue:
Problem spotted in GATK due to smelly use and no use of synchronized in CRAM ReferenceSource: https://github.com/broadinstitute/gatk/issues/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:
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.