6 Replies Latest reply: Feb 18, 2009 2:59 PM by 807557 RSS

    java concurrent in real time environment

    800408
      Hi David,
      we intend to use in our implementation classes from java.util.concurrent.
      for example:
      BlockingQueue, hashMap etc... .
      i read in some documentation from 2006 that jrts not working well
      with this packages.
      is it still relevant for now???
      second question (it more request than a question):
      when we read jrts version we are getting 1.0.2 even our jrts version is 2.1.
      i guess you just need to update the version.

      Thanks

      Gabi
        • 1. Re: java concurrent in real time environment
          807557
          Gabi wrote:
          we intend to use in our implementation classes from java.util.concurrent.
          for example:
          BlockingQueue, hashMap etc... .
          i read in some documentation from 2006 that jrts not working well
          with this packages. is it still relevant for now???
          Yes this is still relevant, nothing has changed. The j.u.c classes in the JDK are built on mechanisms that do not support priority-inversion-avoidance (ie no priority inheritance) and so they are subject to priority inversions. There can also be issues (starvation) with lock-free algorithms when real-time priorities are involved.
          second question (it more request than a question):
          when we read jrts version we are getting 1.0.2 even our jrts version is 2.1.
          i guess you just need to update the version.
          You are confusing the RTSJ (Real-time Specification for Java) with JRTS ( Sun's Java Real-time System). Sun's JRTS Version 2.1 (and 2.0) implement the RTSJ Version 1.0.2

          David
          • 2. Re: java concurrent in real time environment
            800408
            Hi David,
            someone suggest to use j.u.c with synchronize to avoid this problem.
            in my opinion it wont the right way since if it was so easy i guess you already been do that in you jdk's releases.

            what do you think about this suggestion???

            Gabi
            • 3. Re: java concurrent in real time environment
              807557
              Gabi wrote:
              someone suggest to use j.u.c with synchronize to avoid this problem.
              Did they mean that the j.u.c classes should be rewritten to only use synchronized (plus wait/notify) ? You could do that for some of them, but for many of them you would end up with much less performant code. To make j.u.c usable by real-time code all the non-real-time throughput oriented code would suffer. That's not a trade-off that should be made in my view. My view is that if you want real-time utilities then you write real-time utilities. As the RTSJ was defined prior to JDK5 and j.u.c this library issue was not dealt with. (Plus there was a predominant view that the real-time part of the system is small, relatively simple, and doesn't need fancy "support" libraries.

              BTW if I were inclined to rewrite j.u.c I'd probably opt to adding priority-inheritance support to the current mechanisms, rather than downgrading to synchronized et al. That would still kill a lot of performance of course but the end result would be better.

              David
              • 4. java concurrent & real time - do they have a priority inversion issue ?
                807557
                Hi David
                I have a question regarding priority inversion and non blocking alg's:

                Correct me if I'm wrong but priority inversion happend when a low priority threads locks (using java synchronize) an object needed by a high priority thread and therefor preventing the high priority thread to impose cpu preemption.

                Since j.u.c hardly ever use's synchronized but compare and set (non blocking algorithms), how can we have a priority inversion situation ?

                Thanks
                Lior
                • 5. Re: java concurrent & real time - do they have a priority inversion issue ?
                  807557
                  Hi Lior,

                  Priority inversion is about anything that can delay a high priority thread waiting for a low priority one which itself is prevented from running because middle priority threads are running. This is not only about the "synchronize" statement or "lock". This is about any scheme that allows threads to cooperate.

                  When you use "synchronize", a RTSJ implementation will use PIP to ensure that the low priority thread is boosted to the high priority. This basically ensure that the delay for the high priority thread is minimized. Thus, using "synchronize" is a way to avoid priority inversion in your application, not what causes the priority inversion.

                  However, when you use the locks defined in j.u.c (like java.util.concurrent.locks.ReentrantLock), the high priority thread can be blocked on that lock and will not boost the low priority thread. If there are several thread trying to acquire the lock, it is not even guaranteed that the highest priority contender will get it when it is released. Other policies like FIFO can be implemented. It might in some cases be the right policy for your application... but you must be aware of the policy if this is in the time-critical part of your application.

                  Similarly, suppose you implemented the management of a resource with a java.util.concurrent.Semaphore. The low priority thread could own a resource and is expected to release() it when it no longer needs the resource. If the high priority thread needs the same resource, it has no way to boost the low priority thread to speed-up the process. In the worst case, the low priority thread could be completely preempted by other real-time threads and may never use and release the resource. This applies to all the synchronizers in j.u.c (CyclicBarrier, Exchanger, ...). This is not necessarily an issue. This may be the behavior you want.

                  Last example, suppose you want to use a ThreadPoolExecutor to automatically parallelize some work. You must be aware that this does not take into account the priority of the thread that needs that job to be executed. Once again, this is OK if this work is not in the time-critical part of your application and if the thread that is waiting for the job does not own a resource that could be necessary for a higher priority thread.

                  As a summary, if you use j.u.c, you must take into account the fact that there will be no boosting and no guarantee based on the priority. If you are sure that priorities do not matter, then you can use j.u.c. and benefit from these extended APIs .

                  Bertrand.

                  Edited by: delsart on Feb 18, 2009 5:11 PM
                  • 6. Re: java concurrent & real time - do they have a priority inversion issue ?
                    807557
                    And further to Bertrand's comments, for non-blocking algorithms the issue is that given a typical CAS-loop:
                    while (true) {
                      read state
                      compute next state
                      if ( compareAndSet(state, new, expected) == expected)
                        break;
                    }
                    the CAS of a high priority thread can fail an "arbitrary" number of times due to concurrent actions (on a MP system) in other lower (equal or higher) priority threads - where "arbitrary" depends on the number of threads using the code and the way in which the code is used. This isn't the "classic" lock-based priority-inversion scenario, but as Bertrand said, that is just an example of priority-inversion not the definition.

                    David