[concurrency-interest] Target CPU utilization
matthias.ernst at coremedia.com
Fri Feb 16 03:04:40 EST 2007
On a related note: how do you size your pools? Do you really go ahead and size them for each machine they are deployed on? Do you use Runtime.getAvailableProcessors() * ASSUMED_BLOCKING_RATIO?
I'm asking because the .NET runtime provides a vm wide thread pool that reacts to the load conditions and adds more threads if the system is underutilized - albeit slowly (every 500 seconds). I've been wondering whether that is a good idea or an MSFT looks-easy-but-ignores-the-realities feature.
From: concurrency-interest-bounces at cs.oswego.edu on behalf of Joe Bowbeer
Sent: Fri 2/16/2007 01:27
Subject: Re: [concurrency-interest] Target CPU utilization
The specifics depend on how your service is expected to be used. For
example, can it be invoked as-needed by a SwingWorker-style task? Or
does it churn away in the background?
Staying out of way of the GUI is especially important in the latter
case. Lowering the priority of your worker threads may be enough to
keep the GUI from dragging or sputtering.
If your service runs on-demand (and the user is essentially waiting
for you to finish), then providing prompt cancellation and periodic
progress reports is usually sufficient.
It looks like NetBeans and Eclipse have modes where a background task
can be foregrounded, and vice versa.
For the best integration (both in terms of UI and managing load), yes,
it can be important to leverage the platform's existing executors.
On 2/15/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> How do I best integrate a library into an application context which is
> unknown beforehand (in terms of thread pools)? Do I have to share
> pools with the enclosing applications?
> For example assume our library is used in a GUI application which
> itself is built on the NetBeans platform. NetBeans has its own kind of
> thread pools: http://www.netbeans.org/download/dev/javadoc/org-openide-util/org/openide/util/RequestProcessor.Task.html.
> Does my library have to provide hooks where the application can have
> my libraries use the thread management of NetBeans?
> Or is the best approach "laisser fair, laisser aller"? And leave it to
> "the invisible hand" of the OS scheduler to arbitrate between the
> threads of coexisting thread pools?
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest