[concurrency-interest] missed deadlines.

David Holmes 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.

Cheers,
David
  -----Original Message-----
  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
with the
      > max-intended size? After all there is no cost associated with idle
threads
      is
      > there?

      Sure there is - they use up OS threads, stack space etc. If they
didn't we
      wouldn't need thread pools we would just keep as many idle threads as
we
      wanted.

    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
around?
    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
have
      an unbounded potential arrival rate for tasks. If the task arrival
rate is
      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
and
      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...
URL: /pipermail/attachments/20060707/2d88850b/attachment.html 


More information about the Concurrency-interest mailing list