Re: Synchronization questions
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] I've been hacking the tree methods in Node recently ... Are you talking 'maintenance vs. HEAD' here? No. I realise the message was ambiguous. I was talking about versions of my general tree-handling classes - Node (primarily) and Tree. 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...) In this case they do need such access. The inner classes are iterators. 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.) 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. 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) This would be the clean way to express the current version of the code. 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. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Synchronization questions
Peter B. West wrote: This would be the clean way to express the current version of the code. 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. 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. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Synchronization questions
-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
Nasty layout bug: maint vs. HEAD
Tried the following type of FO-document: - one page-sequence with a sort of TOC, a fo:table with basic-links to detail-blocks - multiple page-sequences, one for each detail-block In the test document, the TOC is about five pages, containing links to +/- 300 detail-blocks. The detail-blocks all take up one page each (for the moment). In 0.20.5 this works very fine... In HEAD strangely the document is layed out such that the first TOC page ends up after the last detail-block for which it contains the link... Does anybody have an idea where the origin of this weirdness might be located? :) Cheers, Andreas
Re: Nasty layout bug: maint vs. HEAD
Andreas L. Delmelle wrote: In 0.20.5 this works very fine... In HEAD strangely the document is layed ^ laid :-) out such that the first TOC page ends up after the last detail-block for which it contains the link... I don't understand the problem. Could you trim it down to two detail blocks, and post the FO (assuming the trimmed down FO still has the problem)? J.Pietschmann
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
On Mon, Jan 26, 2004 at 11:32:22AM -, [EMAIL PROTECTED] wrote: This patch is intended as inspiration and as an example of the discussion found here: http://marc.theaimsgroup.com/?l=fop-devm=107511296910230w=2 The patch includes the following: - unnests the Property.Maker classes. - moves the PropertyMakers into properties - Rolls the datatypes into the property classes. - Moves the property classes into datatypes. I have the following considerations: 1. The old situation has pure datatypes, which in theory may be reused in other situations. In practice, these datatypes are very much bound to properties, so that reuse is not realistic, and does not happen in FOP code. Combining the notions of datatype and property is more tuned to FOP's situation. 2. Even in the old situation the separation between datatypes and properties is not complete. Compound datatypes contain properties. 3. In code where the datatype aspect is used, the code may become less logical. This happens in the parsers and in the RTF renderer. An example from render/rtf/TextAttributesConverter.java: // Cell background color ColorTypeProperty colorTypeProp = (ColorTypeProperty)propertyList.get(Constants.PR_COLOR); if (colorTypeProp != null) { ColorTypeProperty colorType = colorTypeProp.getColorType(); if (colorType != null) { if (colorType.getAlpha() != 0 || colorType.getRed() != 0 || colorType.getGreen() != 0 || colorType.getBlue() != 0) { rtfAttr.set( RtfText.ATTR_FONT_COLOR, convertFOPColorToRTF(colorType)); } Here colorTypeProp and colorType denote the same, and the code is not quite logical. That is because the method getColorType now more acts as an assertion. In the new situation it could be made more logical as follows: // Cell background color ColorTypeProperty colorType = (ColorTypeProperty)propertyList.get(Constants.PR_COLOR); if (colorType != null colorType.getColorType() != null) { if (colorType.getAlpha() != 0 || colorType.getRed() != 0 || colorType.getGreen() != 0 || colorType.getBlue() != 0) { rtfAttr.set( RtfText.ATTR_FONT_COLOR, convertFOPColorToRTF(colorType)); } Therefore, in the new situation people might want to do some rewriting. All in all I think that this change simplifies the code, and would be a good change. Allow me to make some notes: 1. Would it not be a good idea to move Property.java from fo to properties? 2. TableColLength and LinearCombinationLength do not have the word 'Property' in their name. I would advocate making these names consistent with the others. 3. Should ToBeImplemented.java also be removed? A lot of good work. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] snip / All in all I think that this change simplifies the code, and would be a good change. Allow me to make some notes: 1. Would it not be a good idea to move Property.java from fo to properties? A question that was on the tip of my tongue too... I'd think: not only Property.java, but all related Maker-classes as well. snip / 3. Should ToBeImplemented.java also be removed? In the long run, that *should* be the objective indeed. For the moment, I'd leave that right where it is, until we're sure we've no more refs to it hidden somewhere else in the code. Cheers, Andreas
RE: Nasty layout bug: maint vs. HEAD
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Andreas L. Delmelle wrote: In 0.20.5 this works very fine... In HEAD strangely the document is layed ^ laid :-) Ahem... Sorry 'bout that. out such that the first TOC page ends up after the last detail-block for which it contains the link... I don't understand the problem. Could you trim it down to two detail blocks, and post the FO (assuming the trimmed down FO still has the problem)? Sure. In attach. Cheers, Andreas testrekov.fo Description: Binary data
Re: Updating licenses
Very cool! I did the whole thing manually back when I exchanged the illegal short licence with the long one. But I noticed the following: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1 It looks like the {YEARS} marker seems not to have worked on some files you checked in yesterday. On 30.01.2004 00:00:46 Peter B. West wrote: Fops, I have committed the perl script bin/lic_to_2 in FOP_0-20-0_Alt-Design. It's function is to substitute license 2.0 for 1.1. It is called as $ lic_to_2 --lic2 {file containing license 2.0 text} {file to modify} The intended usage is something like: $ find . -name '*java'|while read file;\ mv $file $file.orig;\ do lic_to_2 --lic2 {lic2 file} $file.orig $file;\ done I have already committed java and plain text versions of 2.0 to the root directory of FOP_0-20-0_Alt-Design. Note that these license files contain a {YEARS} marker which is replaced from the actual years in the source file copyright notice when the script is run. When we get the OK, I'll use this to update the licenses in alt-design, and, if that works, I can also do the maint and HEAD sources. Jeremias Maerki
DO NOT REPLY [Bug 17999] - @border in fo:block : overwrites area page margin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999 @border in fo:block : overwrites area page margin --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 22:46 --- Created an attachment (id=10171) PDF illustraion
DO NOT REPLY [Bug 17999] - @border in fo:block : overwrites area page margin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999 @border in fo:block : overwrites area page margin --- Additional Comments From [EMAIL PROTECTED] 2004-01-31 22:49 --- I've attached a illustrating PDF example There is a fix though. use padding and set margin to 0. Works for me, see illustration. So maybe there is a bug in the padding calculation routine if margin is not set. Though margin seems buggy too. I've tried to document as good as possible in the pdf. I ran across this when doing an envelope window + folding marker page as you can see. kindest regards, moritz angermann
RE: Nasty layout bug: maint vs. HEAD
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] I don't understand the problem. Could you trim it down to two detail blocks, and post the FO (assuming the trimmed down FO still has the problem)? Sure. In attach. To clear that up a bit further: If you run a document structured like this, but with many more page-sequences, through HEAD, the whole document will be divided into chunks of about 60 pages ( +/- the number of lines in the table-body of the TOC ), and in between you will find the TOC pages themselves. I must admit: it *does* have a certain logic to it I can appreciate, but it would somehow seem far from compliant :) Cheers, Andreas
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
Simon Pepping wrote: I have the following considerations: 1. The old situation has pure datatypes, which in theory may be reused in other situations. In practice, these datatypes are very much bound to properties, so that reuse is not realistic, and does not happen in FOP code. Combining the notions of datatype and property is more tuned to FOP's situation. Alt-design has completely separate properties and data-types. Instances of datatypes contain int references to the property on which they were defined. 2. Even in the old situation the separation between datatypes and properties is not complete. Compound datatypes contain properties. Alt-design has no compound properties. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Updating licenses
Jeremias Maerki wrote: Very cool! I did the whole thing manually back when I exchanged the illegal short licence with the long one. But I noticed the following: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1 It looks like the {YEARS} marker seems not to have worked on some files you checked in yesterday. Ahem... That's because I cut-and-pasted the 2.0 license file into the pattern Eclipse uses when constructing a new class. I forgot to fix {YEARS}. Those new files haven't been run through the perl filter. Thanks for picking this up, Jeremias. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
cvs commit: xml-fop/src/java/org/apache/fop/area BlockContainer.java BlockArea.java ReferenceArea.java
pbwest 2004/01/31 21:47:38 Modified:src/java/org/apache/fop/area/inline Tag: FOP_0-20-0_Alt-Design InlineArea.java InlineContainer.java src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design BlockContainer.java BlockArea.java ReferenceArea.java Log: Fixed Copyright year. Revision ChangesPath No revision No revision 1.2.2.2 +1 -1 xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java Index: InlineArea.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.2 diff -u -r1.2.2.1 -r1.2.2.2 --- InlineArea.java 30 Jan 2004 05:52:43 - 1.2.2.1 +++ InlineArea.java 1 Feb 2004 05:47:38 - 1.2.2.2 @@ -1,6 +1,6 @@ /* * - * Copyright {YEARS} The Apache Software Foundation. + * Copyright 2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.1.2.2 +3 -3 xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java Index: InlineContainer.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- InlineContainer.java 30 Jan 2004 05:52:43 - 1.1.2.1 +++ InlineContainer.java 1 Feb 2004 05:47:38 - 1.1.2.2 @@ -1,6 +1,6 @@ /* * - * Copyright {YEARS} The Apache Software Foundation. + * Copyright 2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. No revision No revision 1.1.2.2 +3 -3 xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java Index: BlockContainer.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- BlockContainer.java 30 Jan 2004 05:51:07 - 1.1.2.1 +++ BlockContainer.java 1 Feb 2004 05:47:38 - 1.1.2.2 @@ -1,6 +1,6 @@ /* * - * Copyright {YEARS} The Apache Software Foundation. + * Copyright 2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.1.2.2 +3 -3 xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java Index: BlockArea.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- BlockArea.java30 Jan 2004 05:51:07 - 1.1.2.1 +++ BlockArea.java1 Feb 2004 05:47:38 - 1.1.2.2 @@ -1,6 +1,6 @@ /* * - * Copyright {YEARS} The Apache Software Foundation. + * Copyright 2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.1.2.2 +3 -3 xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java Index: ReferenceArea.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- ReferenceArea.java30 Jan 2004 05:51:07 - 1.1.2.1 +++ ReferenceArea.java1 Feb 2004 05:47:38 - 1.1.2.2 @@ -1,6 +1,6 @@ /* * - * Copyright {YEARS} The Apache Software Foundation. + * Copyright 2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/area TransformMatrix.java
pbwest 2004/01/31 21:49:10 Modified:src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design TransformMatrix.java Log: Fixed Copyright years. Varioable name changes to match type name. Revision ChangesPath No revision No revision 1.1.2.2 +32 -32xml-fop/src/java/org/apache/fop/area/Attic/TransformMatrix.java Index: TransformMatrix.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/TransformMatrix.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- TransformMatrix.java 30 Jan 2004 05:52:13 - 1.1.2.1 +++ TransformMatrix.java 1 Feb 2004 05:49:10 - 1.1.2.2 @@ -4,7 +4,7 @@ *The Apache Software License, Version 1.1 * * - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. + * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved * * Redistribution and use in source and binary forms, with or without modifica- * tion, are permitted provided that the following conditions are met: @@ -57,7 +57,7 @@ import org.apache.fop.fo.properties.WritingMode; /** - * Describe a PDF or PostScript style coordinate transformation matrix (TransformMatrix). + * Describe a PDF or PostScript style coordinate transformation matrix. * The matrix encodes translations, scaling and rotations of the coordinate * system used to render pages. */ @@ -65,11 +65,11 @@ private double a, b, c, d, e, f; -private static final TransformMatrix CTM_LRTB = +private static final TransformMatrix TM_LRTB = new TransformMatrix(1, 0, 0, 1, 0, 0); -private static final TransformMatrix CTM_RLTB = +private static final TransformMatrix TM_RLTB = new TransformMatrix(-1, 0, 0, 1, 0, 0); -private static final TransformMatrix CTM_TBRL = +private static final TransformMatrix TM_TBRL = new TransformMatrix(0, 1, -1, 0, 0, 0); /** @@ -123,15 +123,15 @@ /** * Initialize a TransformMatrix with the values of another TransformMatrix. * - * @param ctm another TransformMatrix + * @param tm another TransformMatrix */ -protected TransformMatrix(TransformMatrix ctm) { -this.a = ctm.a; -this.b = ctm.b; -this.c = ctm.c; -this.d = ctm.d; -this.e = ctm.e; -this.f = ctm.f; +protected TransformMatrix(TransformMatrix tm) { +this.a = tm.a; +this.b = tm.b; +this.c = tm.c; +this.d = tm.d; +this.e = tm.e; +this.f = tm.f; } /** @@ -145,23 +145,23 @@ * TransformMatrix is being set. * @return a new TransformMatrix with the required transform */ -public static TransformMatrix getWMctm(int wm, int ipd, int bpd) { -TransformMatrix wmctm; +public static TransformMatrix getWMtm(int wm, int ipd, int bpd) { +TransformMatrix wmtm; switch (wm) { case WritingMode.LR_TB: -return new TransformMatrix(CTM_LRTB); +return new TransformMatrix(TM_LRTB); case WritingMode.RL_TB: { -wmctm = new TransformMatrix(CTM_RLTB); -wmctm.e = ipd; -return wmctm; +wmtm = new TransformMatrix(TM_RLTB); +wmtm.e = ipd; +return wmtm; } -//return CTM_RLTB.translate(ipd, 0); +//return TM_RLTB.translate(ipd, 0); case WritingMode.TB_RL: { // CJK -wmctm = new TransformMatrix(CTM_TBRL); -wmctm.e = bpd; -return wmctm; +wmtm = new TransformMatrix(TM_TBRL); +wmtm.e = bpd; +return wmtm; } -//return CTM_TBRL.translate(0, ipd); +//return TM_TBRL.translate(0, ipd); default: return null; } @@ -323,7 +323,7 @@ * (Note: scrolling between region vp and ref area when * doing online content!) */ -TransformMatrix ctm = +TransformMatrix tm = new TransformMatrix(absVPrect.getX(), absVPrect.getY()); // First transform for rotation @@ -332,16 +332,16 @@ // first quadrant. Note: rotation is counter-clockwise switch (absRefOrient) { case 90: -ctm = ctm.translate(0, width); //
Re: Synchronization questions
Andreas L. Delmelle wrote: -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. (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...) Deadlock problems have to be considered carefully at the design stage. 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