3 Replies Latest reply on May 14, 2008 11:43 PM by 807557

    Fairness of "synchronized" locks?


      Does the Sun Real-Time VM attempt to provide fair access to object monitor locks?

      An example - suppose I have three application threads (T1, T2, T3) all running at the same priority. These periodically acquire a lock on a shared object :-
       while (true) {
        synchronized (sharedObject) { 
      Are attempts to acquire an object monitor lock queued, so that all threads will eventually make some progress? Or is it possible to get into a pathological condition where threads T1 and T2 could be constantly grabbing the lock - leading T3 to be starved, and blocked for an unpredictable amount of time? I was under the impression that standard Java just made the blocked threads "recontend" for the lock after the owning thread had released it, and I'm not sure if the RTJ VM has inherited this behaviour, or done something more sophisticated.

      Any clarifications would be welcome :-)

        • 1. Re: Fairness of "synchronized" locks?
          The RTSJ requires that monitor locks are granted based on execution-eligibility and then FIFO within the same execution-eligibility.

          David Holmes
          • 2. Re: Fairness of "synchronized" locks?
            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,
            • 3. Re: Fairness of "synchronized" locks?
              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.

              David Holmes