[concurrency-interest] Target CPU utilization

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Fri Feb 16 09:26:40 EST 2007

In my previous mail, I meant:
'this "background" flag being then propagated across threads involved'
instead of
'this "background" flag being then propagated across thread-pools involved'


On 2/16/07, Ernst, Matthias <matthias.ernst at coremedia.com> wrote:
> 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.
>  Matthias
>  -----Original Message-----
>  From: concurrency-interest-bounces at cs.oswego.edu on behalf
> of Joe Bowbeer
>  Sent: Fri 2/16/2007 01:27
>  To: concurrency-interest
>  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:
>  > 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
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070216/5aa55360/attachment.html 

More information about the Concurrency-interest mailing list