[concurrency-interest] missed deadlines.
dcholmes at optusnet.com.au
Fri Jul 7 00:02:25 EDT 2006
This is all "best effort" stuff with no pretense at real-time. That means
running late should at worst yield no value, not incur damage. If your needs
are more stringent then that, then you are working with the wrong platform.
Scheduling depends on things both inside and out of the VM.
But I think what was being looked for here was just a way to detect that
something ran much later than expected and so skip it.
From: Dhanji R. Prasanna [mailto:dhanji at gmail.com]
Sent: Friday, 7 July 2006 1:57 PM
To: dholmes at ieee.org
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] missed deadlines.
Also does the issue of missed deadlines not also cross over to timing
semantics? Couldnt the gc cause threads to be pre-empted at any time (even
if there are plenty available in the pool) and create missed deadlines...
I guess what is bothering me is without RTSJ, is there any meaningful way
to address the deadlines issue?
On 7/7/06, Dhanji R. Prasanna < dhanji at gmail.com> wrote:
On 7/7/06, David Holmes <dcholmes at optusnet.com.au> wrote:
Dhanji R. Prasanna writes:
> Re auto-creation of pools, what is wrong with simply starting out
> max-intended size? After all there is no cost associated with idle
Sure there is - they use up OS threads, stack space etc. If they
wouldn't need thread pools we would just keep as many idle threads as
Surely the cost of starting new threads (and killing excess idle ones)
is greater than the cost of keeping a reasonable number of idle threads
perhaps I should have rephrased "no cost" to "comparatively less cost".
Having an unbounded maximum number of threads can be a bad idea if you
an unbounded potential arrival rate for tasks. If the task arrival
limited then so is the thread creation rate.
Yea, I cant think of when an unbounded max # of threads is ever a good
idea? Even at OS-level semantics...
ScheduledThreadPoolExecutor sets up the ThreadPoolExecutor queueing
threading behaviour is a very specific way: the queue is effectively
unbounded so only coreSize comes into play. Given that, there is less
control over how ScheduledThreadPoolExecutor behaves.
This is how I read it STPE is a specialization of TPE. Peter made a fair
comment to me, that perhaps STPE should have embedded/delegated to TPE
rather than extended from it (to avoid contract confusion).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest