Question

I have an archive object which manages various byte arrays and hands out InputStreams and OutputStreams for reading and writing them. Each byte array has an associated ReentrantReadWriteLock.

The constructor of the subclass of InputStream which the archive produces acquires the lock for the relevant data, while close() releases the lock. Now, the problem:

Suppose that I have a task which will run on another thread which needs input from the archive, is given the InputStream as an argument before it starts, and is responsible for closing the stream when it’s finished. These requirements appear to be incompatible with the locking mechanism used by my data archive, because

1. The InputStream is created on a different thread from the one on which it is closed.
2. A ReentrantReadWriteLock must be released by the thread which owns it.

Rewriting the parts of the program which expect an InputStream as input in order to avoid #1 is inconvenient and makes those parts less flexible. Using a kind of lock which permits change of ownership would let me avoid #2, but I don’t see any locks in the Java API which can handle that and I’m not terribly keen on knocking together a custom lock if I don’t have to.

What solutions are there to this problem?

Answer 1

The cleanest way to do this is to give the clients something other than a subclass of InputStream, even if this means slightly more refactoring. In your current design, you can’t count on your clients releasing the lock, what if one of them does not? This is not good encapsulation.

Have the archive object manage the locks, and provide an easy API for your clients to get the data. Even if this means changing some APIs.

The problem of different threads locking and releasing the same object is a clear sign that you got something slightly wrong in your current design. Work on the refactoring aforementioned, it will do you a great deal further on.