...-----Original Message----- From: Peter B. West [mailto:[EMAIL PROTECTED]
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)
This is always going to be tricky.
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.
See comments below.
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.
It's only necessary to synchronize the methods that read or modify the data that is in contention. I suspect that a lot of synchronized code is written by those who don't quite understand why, and who take the first approach that seems to work. I get the feeling that quick and easy approaches are frequently encouraged.
Deadlock problems have to be considered carefully at the design stage.(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...)
In my original considerations for the pipelined model of alt-design, I was happy to have blocking writes/reads on the buffers of the primary pipeline (parser->fo tree builder->area tree builder), but I thought there would be deadlock problems if the return message queues were blocking. (See figure 3 - incorrectly captioned Figure 2 - of http://xml.apache.org/fop/design/alt.design/xml-parsing.html). I believe that the less complicated the synchronization structure, the easier it will be to analyse the possibilities for deadlock, hence my interest in getting back to more "global" synchronization objects.
<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)?
It seems to be the only way to do it.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
