locking in zipfs demo
Alan.Bateman at Sun.COM
Fri Dec 4 05:17:08 PST 2009
Rajendra.Gutupalli at Sun.com wrote:
> Alan Bateman wrote:
>> Joel Uckelman wrote:
>>> I'm puzzled by the ReentrantReadWriteLock used in ZipFilePath in
>>> place. It seems to be locking calls to getResolvedPathForZip(), which
>>> sets the pathToZip member if it's null. Is there a reason for using a
>>> lock for this instead of making pathToZip volatile like the offsets
>>> ArrayList is?
>> It looks like it was intended to support asynchronous close of the
>> zip file system, in which case it should be using fs.begin() and
>> fs.end() rather than its own lock (Rajendra - can you confirm this?).
> Hi Alan,
> I am alive :-) gone into snooze mode on jdk7 and working on
> different projects. Sorry for delay in responding the mail.
> The main intention of using lock is for each operation that accesses
> the zip file acquires the read lock, tests if the file system is
> closed and if so throws ClosedFileSystemException
> and at the end releases the lock. The close method acquires the write
> lock and will wait until all threads are finished access the zip file.
Thanks for confirming this - it looks like the readLock should be
removed from ZipFilePath and its begin/end methods should be changed to
invoke filesystem.begin() and filesystem.end(). That way operations on
ZipFilePath will be work with the asynchronous close mechanism.
Joel - do you want to take this one?
More information about the nio-dev