This content has been marked as final. Show 3 replies
The RTSJ requires that monitor locks are granted based on execution-eligibility and then FIFO within the same execution-eligibility.
Thanks. The spec does indeed spell this out, once I'd thought to look at it properly :-)
Just as a follow-up - I have been told that some of the java.util.concurrent classes might do some "odd" things when running under the Real Time VM.
Some of the blocking container classes (such as ArrayBlockingQueue) use the LockSupport park() and unpark() methods to suspend and reschedule threads (e.g., when a thread is blocked on a put/take). These are implemented with the sun.misc.Unsafe.park() and unpark() primitives, which call into native code. Have these primitives been modified in any way in the Real Time VM? Is there any FIFO ordering when using the LockSupport primitives? Should they be avoided under RTJ?
The ArrayBlockingQueue does have a "fairness" parameter which (when enabled) looks like it implements a FIFO queue for threads blocked on the container - I'm assuming this would still work under RTJ should we need it.
Thanks for your help,
The java.util.concurrent utilities have not (and can not be) modified for RTSJ. These utilities do not provide priority ordering for acquisition; they use lock-free data structures which could lead to thread starvation; and in general they do not provide any form of priority inversion avoidance.
Now if all your threads have the same priority then perhaps j.u.c will work for you.
The FIFO queues will still be FIFO but they can also suffer from priority inversions etc in their synchronization code.