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
import java.util.ArrayList;

public class RunnableArrayList
extends      ArrayList
implements   Runnable
{
	public void run() {
		for (int N = size(), i = 0; i < N; ++i)
			try {
				((Runnable)get(i)).run();
			}
			catch (Exception e) {
				e.printStackTrace();
			}
		clear();
	}
}
// end of file
-------------------------------------------------------------------------
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

Reply via email to