> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED] > > I've been hacking the tree methods in Node recently, triggered by the > need to construct multiple subtrees during area tree construction, > cobbling them together as necessary. In the original version, I was > able to synchronize on the Node's containing Tree instance, but that is > no longer feasible, as Nodes may be free-floating. >
Are you talking 'maintenance vs. HEAD' here? > My first change was to synchronize the methods which had previously been > synchronized on the Tree, but I realized that such synchronization of > methods in inner classes probably only synchronized on the actual inner > class instance, not on the containing class instance. Does anyone have > any knowledge of this? > Hmm... Difficult to tell from the docs I read, so far... I'd say: indeed, unless the code-block through which the inner class (synchronized) method is accessed is synchronized on the containing class instance, no? Then again, synchronizing only on the inner classes could turn out to offer more flexibility, as other operations on the containing class can still be carried out while the inner class is locked (provided, of course, that the 'other' operations do not need access to the inner class instance...) > It also occurred to me that optional synchronization might be a good > idea, allowing a common synchronization object to be passed to the Node > constructor. An alternative was to allow optional synchronization, but > to synchronize on the affected Node object. On the construction of any > particular Node, a boolean can be passed indicating the need for > synchronization. The other solution for the above stated issue: remove the synchronization from the inner class methods, and synchronize their bodies on the containing class instance. (Again: IIC you'd only need this if you really *need* to synchronize on the outer class... if you don't, I guess the approach you're taking now is more flexible and less likely to lead to deadlocks.) <snip /> > > Does anyone have experience with such issues? > No real experience, but thinking about 'optional synchronization' brings up all sorts of ideas, like: - a Lockable interface for Nodes - a SyncedNode extending Node implementing the Lockable interface - when you really only need a non- or partly synchronized Node use the main type; if you need a fully synchronized one, use the subtype (ratio of execution speeds from non-synced vs. synced is roughly 100 vs. 150, so it would definitely be worth it to avoid synchronization altogether where it is not strictly necessary) Then again, perhaps even too little experience to be able to tell the exact (dis)advantages of this idea, so feel free to point out any errors in logic... Cheers, Andreas
