locking in zipfs demo

[Alan Bateman]

Rajendra.Gutupalli at Sun.com wrote:
> Alan Bateman wrote:
>> Joel Uckelman wrote:
>>> I'm puzzled by the ReentrantReadWriteLock used in ZipFilePath in 
>>> various
>>> 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?

-Alan.