Sascha and Larry, I must admit that I am way over my head here. I haven't done much thread programming in Java. (Hopefully Stefan has!)
Sascha wrote: "My primary goal is to simplify the threading code to make it more reliable in terms of time." This seems like an admirable goal to me. If Larry, or a similar programmer of his experience, agrees that this changes would be beneficial, I say we give Sascha a shot at it. It sounds like she has considered her changes carefully. Just my two cents. The Sunburned Surveyor On 5/24/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > Hi Larry, > > short answer first: No, I don't have any benchmarks, yet. > > The long answer: My primary goal is to simplify the > threading code to make it more reliable in terms of time. > Gaining performance improvements would be a neat side effect. > > Background: Multi-threading may be fine for slow layers > which arrives later on the screen but for exporting > the data (to print/layout e.g) it would be nice to have > them arriving one after the other. > > My final goal is to have a simple switch between the normal > and the serial mode. To archive that I try to carefully > refactor the system doing little patches step by step > not to break it. Refactoring the ThreadQueue with it's > 'flaws' seems a to be a good starting point to me. > > One reason for this change is the fact that you are able > to figure out if the default thread runs empty. But there > is no way to figure out when the last thread ends. That > are different things. A mechanism for this is planned. > > Sorry, if I've shadowed my true intentions to much. Maybe > I should discuss more before I send patches. ;-) > > Back to the technical side: > > The patch needs some testing but I don't expect too much > performance improvement. > > A less intrusive alternative to bind the Runnables that go to the > default ThreadQueue into one thread is to create a container > which self is Runnable (see e.g. RunnableArrayList attached) > and put them into an instance of this class. > This container is put into multiRendererThreadQueue as a Runnable. > With this modification the defaultRendererThreadQueue can > be removed (multiRendererThreadQueue renamed to > defaultRendererThreadQueue). Only an idea ... I'm in discussion > mode now. ;-) > > - Sascha > > > Larry Becker schrieb: > > Hi Sascha, > > > > I read your comments and look at your code with interest. It appears > > to be an improved ThreadQueue implementation, but will require a lot of > > testing to verify. Before I invest this time, I would like to know what > > problem it is solving. I see your dislikes a - e, but these are not > > really problems, only architectural critiques. Have you done any > > benchmarks that show that the new SingleThreadQueue speeds up > > rendering? Your logical argument that it should be more efficient is > > persuasive, but I have been surprised by Java before. > > > > respectfully, > > Larry Becker > > > > On 5/23/07, *Sascha L. Teichmann* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Hi together, > > > > as some of you may already know i have my dislikes against > > ThreadQueue [1] (Hi, Larry!) see my mail [2] > > > > a - It forks a new thread for any Runnable it processes. > > b - It has an ugly busy wait loop inside. > > c - The event listener for empty queue fires to often. > > d - The default ThreadQueue is some kind of thread serializer. > > e - The DB/WMS ThreadQueue has no public access. > > > > Now I've written a sub class of ThreadQueue: SingleThreadQueue > > (see attachment). This one deals with the issues a, b and d. > > I also attached a patch against RenderingManager [3] to handle e. > > > > The new class (to be placed in package > > com.vividsolutions.jump.workbench.ui.renderer) is a drop-in > > replacement for the default ThreadQueue in RenderingManager. > > Not for the ThreadQueue that handles the DB/WMS layers. > > > > Because Jon limited the number of parallel threads in default > > queue to 1 I see no reason why to fork a new thread for each > > Runnable it processes. Thread creation/shutdown is fairly > > expensive. Instead a single background thread is started > > which processes the Runnables one by one. If the thread > > is idle for 30 secs it shuts itself down. If you have a lot > > of (non-WMS/BB) layers this should improve performance > > and save some resources. The processing itself is done > > with a monitor (synchronized/wait/notify) so there is no > > busy wait any more. > > > > The DB/WMS ThreadQueue (real parallel threads) is left untouched > > for the moment. Depending on my personal schedule I will send > > a patch against this one too. Preliminary code with thread pooling > > exists but it needs a bit more testing. > > > > Find attached the new class and patches against RenderingManager and > > the old ThreadQueue to bring it to work. > > > > Comments are very welcome. :-) > > > > Kind regrads, > > Sascha > > > > [1] com.vividsolutions.jump.workbench.ui.renderer.ThreadQueue > > [2] > > > > http://sourceforge.net/mailarchive/message.php?msg_name=4653389E.6000706%40intevation.de > > [3] com.vividsolutions.jump.workbench.ui.renderer.RenderingManager > > > > Index: > > > > ./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java > > > > =================================================================== > > RCS file: > > > > /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java,v > > retrieving revision 1.6 > > diff -u - r1.6 RenderingManager.java > > --- > > > > ./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java > > 22 May 2007 18:47:12 -0000 1.6 > > +++ > > > > ./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java > > 24 May 2007 04:10:30 -0000 > > @@ -77,7 +77,7 @@ > > * non-database layers in parallel. In fact, it will make > > the GUI less > > * responsive. [Jon Aquino] > > */ > > - private ThreadQueue defaultRendererThreadQueue = new > > ThreadQueue(1); > > + private ThreadQueue defaultRendererThreadQueue = new > > SingleThreadQueue(); > > > > /** > > * WMS and database processing are done on the server side, > > so allow these > > @@ -294,6 +294,10 @@ > > return defaultRendererThreadQueue; > > } > > > > + public ThreadQueue getMultiRendererThreadQueue() { > > + return multiRendererThreadQueue; > > + } > > + > > public void dispose() { > > repaintTimer.stop (); > > defaultRendererThreadQueue.dispose(); > > @@ -334,4 +338,4 @@ > > contentIDToRendererMap.remove(contentID); > > } > > > > -} > > \ No newline at end of file > > +} > > > > Index: > > ./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java > > =================================================================== > > RCS file: > > > > /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java,v > > retrieving revision 1.1 > > diff -u - r1.1 ThreadQueue.java > > --- > > ./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java > > 16 > > Jun 2005 22:50:38 -0000 1.1 > > +++ > > ./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java > > 24 > > May 2007 04:09:15 -0000 > > @@ -47,6 +47,10 @@ > > private Vector queuedRunnables = new Vector(); > > private int maxRunningThreads; > > > > + public ThreadQueue() { > > + this(1); > > + } > > + > > public ThreadQueue(final int maxRunningThreads) { > > this.maxRunningThreads = maxRunningThreads; > > } > > @@ -95,7 +99,7 @@ > > public static interface Listener { > > public void allRunningThreadsFinished(); > > } > > - private void fireAllRunningThreadsFinished() { > > + protected void fireAllRunningThreadsFinished() { > > //new ArrayList to avoid ConcurrentModificationException > > [Jon Aquino] > > for (Iterator i = new ArrayList(listeners).iterator(); > > i.hasNext(); ) { > > Listener listener = (Listener) i.next(); > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > <mailto:Jump-pilot-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> > > > > > > > > > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
