[concurrency-interest] Real-time task scheduling
hans.boehm at hp.com
Tue May 19 12:37:38 EDT 2009
You're presumably really asking about a particular implementation?
The JLS really says very little about progress guarantees, much less real-time guarantees. It doesn't guarantee that garbage collection is only triggered on allocation. I don't think it guarantees sufficient timer accuracy, etc.
Even then, I suspect there are other issues, e.g. various routines in the runtime and library that ship with the JVM are probably not lock-free.
If the goal is to make this work nearly all of the time on a particular implementation, maybe ...
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf
> Of Jean Morissette
> Sent: Tuesday, May 19, 2009 6:34 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Real-time task scheduling
> Giving a task with an execution cost of sub-microsecond and a
> period in the order of 10 microseconds, I would like to
> schedule periodically this task with hard real-time behaviour
> on the Java SE platform.
> I take as granted the following assumptions:
> (1) All objects in the program are allocated at the start and
> reused such that the GC does not pause the program.
> (2) All classes are loaded and compiled at the start (by
> example running in interpreted mode using -Xint JVM option or
> using AOT compiler like Excelsior JET) avoiding pause from
> JIT compiler.
> (3) No other user-program is running on the OS.
> (4) The number of threads created by the program is lower
> than the number of CPU, avoiding context-switching.
> (5) Concurrency is performed using lock-free data structures.
> (6) OS independance is not a requirement.
> Considering those assumptions are valid, one issue remaining
> is the unpredictability of the OS, which could use the CPU
> for its own needs at any moment, stoping the Java worker
> thread long enough to make the task miss its deadline. Is-it
> possible to resolve this issue?
> By example, assuming that the program run on a Real-Time OS,
> do the OS threads associated with the Java threads will have
> the same priority than the Java program? Otherwise, is-it
> possible to create a JNI call to change the OS thread
> priority associated with the current Java thread such that it
> cant be preempted? Or is-it possible to configure the OS to
> set an upper bound on thread pause time?
> Thanks for your help,
> Jean Morissette
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest