RFR : 8038491: Improve synchronization in ZipFile.read()
sean.coffey at oracle.com
Wed Apr 9 19:10:46 UTC 2014
On 09/04/14 19:36, Alan Bateman wrote:
> On 09/04/2014 18:39, Seán Coffey wrote:
>> On re-read, I believe extending the sync block in read(..) to cover
>> the reading and setting of the rem variable works to resolve this
>> fix. It should preserve behaviour as well.
> This is probably okay for a test case that attempts concurrent reads
> but as it's not synchronized with skip then I don't think you can
> trust the value of rem or pos without taking copies and validating.
I played around with adding some skip testing Alan but didn't see it
increase the rate of failure on an unpatched binary. Since
ZipFileInputStream.read(..) is the trouble method and now has better
synchronized access to reading and updating rem, I believe we're good.
skip(long) can trigger a close() but close() can't free up the resources
without the ZipFile.this lock. As mentioned, having multiples threads
reading from the one zip stream would make no sense anyhow.
Let me know if I need to make changes. I don't think we want to add
extra sync costs to the class.
More information about the core-libs-dev