Java concurrent in real time environment

Question

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

Answer 1

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