Howdy, all --

I'm trying to strengthen Ivy's locking system to make it strong enough to
allow ivy:clean at arbitrary times on systems which can have other actions
making use of the same shared caches.

There are a few requirements to make this happen while still allowing
multiple resolves (and like operations) to occur concurrently. One of those
is maintaining nonexclusive read locks (as opposed to the write locks which
are currently supported), and cleaning them up when necessary. For
ease-of-implementation, I'm currently proposing to only support this
behavior when NIO locks (which implicitly support shared locking semantics)
are enabled.

To clean these locks up without requiring end-user code to be modified, I
propose using the IvyContext stack -- allowing Runnables to be attached to
a stack element, and invoking them implicitly when the stack is popped.


Because converting a read lock to a write lock is inherently prone to race
conditions, we might need to break backwards compatibility with respect to
ivy:clean, allowing this to be called only inside a context where no read
operations have been done -- or breaking read lock semantics by dropping
all read locks before grabbing the write lock.


Thoughts?

Reply via email to