[concurrency-interest] Real-time task scheduling

David Holmes davidcholmes at aapt.net.au
Tue May 19 17:49:42 EDT 2009

Hi Jean,

So what you are really asking is: can I approximate the behaviour of an
implementation of the Real-time Specification for Java (JSR-1, JSR-282), by
constraining the application behaviour in a similar manner to
Safety-critical Java (JSR-302), but do all this on a stock-standard JVM ?

How close you can get depends on the VM you are using. If you remove all GC
activity (not always possible even if you don't allocate) and all
compilation activity (again not necessarily easily accomplished) then there
can still be other activities in the VM that interfere with your application
threads - for example if considering Hotspot, non-GC related safepoints,
periodic WatcherThread, and possibly library level threads like the
ReferenceHandler and Finalizer threads (which in theory can be idle, but in
practice might wakeup occasionally). So getting a VM that will support what
you are trying to do is not easy.

Then there is the OS. Again it depends on which OS but if you are thinking
Solaris or a real-time Linux, or anything that presents a POSIX-like
execution environment then you need to be using the realtime scheduling
classes  of that OS. You need a VM which maps Java threads directly to
native threads. You could use a JNI call to set the priority to the desired
real-time level. But there are a couple of things you need to further

a) you need to prioritize your threads at the correct level relative to
system services, such that you don't execute in preference to OS activities
that you will be relying upon

On Solaris the RT priorities lie between the IRQ priorities (highest) and
the system activities. On RT-linux you can change the priority of anything -
but you need to know what you are doing.

b) Having RT priority threads in your application might break the JVM
because RT priority threads enjoy a run-till-block (or preempted, or
voluntarily relinquish the CPU) scheduling policy, and that can interference
with VM coordination protocols which don't expect this, and which don't
expect strict priority based scheduling.

Your use of lock-free might also be problematic - first because with
priority-based scheduling you can more easily get starvation; but also
because you can't (easily) control all the locks used by Java code so some
regular monitors might be involved as well. Then again if it is a thread per
CPU you could use simply spin-locks because you won't care about the wasted
cycles (but you'll need all threads to have the same priority for it to work

One final issue is that you are unlikely to find a mechanism in a standard
VM that will allow you to schedule a periodic task with microsecond
resolution: Thread.sleep and Object.wait are unlikely to do it. But it
depends on the actual VM implementation.


David Holmes
(VM Engineer on Sun's Java Real-Time System)

> -----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, 19 May 2009 11:34 PM
> 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