> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED] <snip /> > > > > > >>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. > > > [Me :] > > 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.) > >
> I was worried about increasing the probability of deadlock by having > many more locks held concurrently. Without having thought about it a > great deal, it seems to me that it is easier to appreciate and avoid > potential deadlocks when synchronization is more "global", as with the > synchronization on the containing Tree object. > Yes, I see what you mean... Well, as I indicated, there's absolutely no reason to trust me on this. Your view is probably more to the point here. The only thing I do know for sure is that many authors claim that most possible cases of deadlock can --and should preferrably be - identified in advance (i.e. before any code is ever written). The two most common cases of deadlock are AFAIK: 1. A thread that doesn't exit (cleanly), so never releases the lock (threads going into an infinite loop belong to this category) 2. Two threads 'waiting for each other': one holding the lock and waiting for a return value from the second, the other needing access to the locked object in order to return the desired value. So it would come down to predicting in some way the risk of either of these two taking place. I guess that, when synchronization is more global, the first type would be easier to avoid. Mostly, it's also advised not to synchronize *every* method, actually leaving a backdoor opened to be able to cleanly open the lock from the inside (--but I'm guessing this is well-known fact to you). This would be an argument against all-too-eagerly-global synchronization IMHO. (On top of that, but this may be a consequence of the limitation of my understanding of the FO process in its entirety, it seemed easier to me to avoid the first cases manually and the second by design, than doing it the other way around. I'm still not completely familiar with the 'borderline' cases, where an event downstream would influence upstream events in such a way that they might need access to a Node on which a lock is being held by another process...) > > <snip /> > However, I am still toying with the idea of allowing (sub)trees to > synchronize on an object passed in as a parameter to the Node > constructor. If the object reference is null, synchronization is turned > off. In this scheme, I would allow subclasses (like Area) to switch > synchronization on by setting the 'sync' object non-null, as, for > example, when a locally constructed subtree was grafted onto the > AreaTree. It also returns to the situation of a common synchronization > object for each node in the (sub)tree. > > [Your follow-up: ] > The notion of switching synchronization on and off is, unfortunately, > brain-dead. If synchronization is to be changed, then the code which > changes and reads the synchronization state must itself be synchronized. > > The conditional synchronization that I have now is only workable because > the setting for any particular node is immutable. And so if you need a non-synched version of the same Node, you would need to create a non-synched clone/copy (--preferrably disposable)? Cheers, Andreas
