Hi,
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.
Michael
