jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Inconsistent locking in TreeImpl.Children?
Date Wed, 29 Aug 2012 09:26:32 GMT


On 28.8.12 16:37, Marcel Reutegger wrote:
> TreeImpl.Children.iterator() returns an iterator over the values of the internal children
Map without locking. Other methods accessing the children Map use read or write locks, depending
on the operation.
> I'm wondering if locking is missing there or if it is even needed.

The thinking is that the iterators returned from Tree have snapshot 
semantics. That is, they represent the state of the underlying tree at 
the point the iterator was returned. Later changes are not reflected nor 
do mutating calls to the tree from within such an iterator result in a 
ConcurrentModificationException. See the Javadoc for Tree.getChildren. 
While the initial design might have deteriorated to some degree I think 
the general contract still holds. Furthermore locking should not be 
necessary since by contract Tree instances are not thread safe.

BTW. Children.iterator is currently never called at all. It is a 
leftover from an earlier implementation where the caller ensured the 
contract described above would hold.


View raw message