[concurrency-interest] Real-time task scheduling

Boehm, Hans 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 ...

Hans 

> -----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
> 
> Hi,
> 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 


More information about the Concurrency-interest mailing list