[concurrency-interest] Target CPU utilization

Brian Goetz brian at quiotix.com
Thu Feb 15 18:21:23 EST 2007


All this said, usually U=1.  And, realistically, setting three pool 
sizes does not have to be that exact, as long as you avoid the extremes 
of "way too small" and "way too big".

That said, if you have a library which will be managing threads, you 
need to present it to the application as a service, with lifecycle 
methods like shutdown().  Otherwise, your user's applications will not 
be able to shut down.  And, if you have a lifecycle interface, that 
gives you room to let the user supply (optionally) an Executor to be 
used to process tasks.

Peter Kovacs wrote:
> I've been thinking a lot about this. The major challenge about this
> aspect in my case that I am facing the task of making a library
> multi-threaded. The library will then be sold and built into custom
> applications.
> 
> 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?
> 
> Thanks
> Peter
> 
> On 2/15/07, Brian Goetz <brian at quiotix.com> wrote:
>> Another is that you might have multiple thread pools within an
>> application, and want to allocate (coarsely) CPU cycles to different
>> activities.
>>
>> David Holmes wrote:
>> > Two possibilities I can think of straight away:
>> >
>> > - You might not be the only application trying to run on the system.
>> > - You might want to allow room for handling transient overload.
>> >
>> > Others?
>> >
>> > David Holmes
>> >
>> >
>> >> -----Original Message-----
>> >> From: concurrency-interest-bounces at cs.oswego.edu
>> >> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
>> >> Kovacs
>> >> Sent: Friday, 16 February 2007 7:13 AM
>> >> To: concurrency-interest
>> >> Subject: [concurrency-interest] Target CPU utilization
>> >>
>> >>
>> >> Hi,
>> >>
>> >> The function determining the optimal pool size includes the target CPU
>> >> utilization as a factor. What are the typical reasons why one would
>> >> want its value to be less than 1?
>> >>
>> >> Thanks
>> >> P.
>> >> _______________________________________________
>> >> 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
>>


More information about the Concurrency-interest mailing list