Le 3 janv. 2014 à 22:28, Charles Duffy <char...@dyfis.net> a écrit :
> 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? My first blind though would be that IvyContext seems to be high level to handle locking. Couldn't it be done by improving the LockStrategy interface so that it also handles read locks ? Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
