This discussion is archived
3 Replies Latest reply: May 5, 2009 2:48 AM by 807557 RSS

Difference between RTT and normal threads

807557 Newbie
Currently Being Moderated
We all know that realtime threads are really powerful when we use it with memory area, priority control, atc, etc. But i guess i have a conceptual doubt :
In a scenario where we have a thread that creates thread objects through a declaration like Thread t = new Thread() and execute them afterwards, if we change the declaration to Thread t = new RealtimeThread(), creating lots of threads without specifying any other parameter (so they would all have the same priority)... would it change something?
  • 1. Re: Difference between RTT and normal threads
    807557 Newbie
    Currently Being Moderated
    Yes it will change the scheduling behaviour of the application:

    - it will change the relative scheduling of the creating thread and the created ones

    eg. after creating a few RTTs the main thread might get starved out (assuming it isn't also RTT)

    - it will change the relative scheduling of the created threads

    Plain Threads will get time-sliced, RTTs will execute run-to-block. If the application code makes any assumptions about relative scheduling then you could get livelocks/starvation or in general undesirable behaviour.

    - it will change the relative scheduling of the created threads and the other applications and system services running on the machine

    RTTs will run in preference to all non-RT applications and system services.

    - it can change how the RTGC (assuming Java RTS) interacts interacts/affects the created threads

    Normal threads will always be preempted by GC; RTTs only get preempted if the RTGC is boosted.


    David Holmes
  • 2. Re: Difference between RTT and normal threads
    807557 Newbie
    Currently Being Moderated
    Thanks once again for answering, David.

    - Just to verify if i got what you meant (as you may notice by my english skills, i'm not a native english speaker and i don't know all informatics' terms in english) : When you say "run-to-block" you mean that the thread with the highest priority will run until it's blocked?
    - That's another question i had about RTT threads and its behavior in RT systems : their priority is considered in the scheduling of all the system applications? Or it's only relative to the virtual machine (i mean, the big process Java with all its threads is considered to the scheduling or each thread in particular is considered)?
  • 3. Re: Difference between RTT and normal threads
    807557 Newbie
    Currently Being Moderated
    jcamerico wrote:
    Thanks once again for answering, David.

    - Just to verify if i got what you meant (as you may notice by my english skills, i'm not a native english speaker and i don't know all informatics' terms in english) : When you say "run-to-block" you mean that the thread with the highest priority will run until it's blocked?
    Yes, a thread in the real-time scheduling class will run until it is either preempted by a higher-priority thread, or else it voluntarily gives up the CPU (which occurs if the thread blocks (I/O, monitor acquisition, wait(), sleep() etc) or yields (and yield only makes a difference if there are threads of the same priority ready to run).
    - That's another question i had about RTT threads and its behavior in RT systems : their priority is considered in the scheduling of all the system applications? Or it's only relative to the virtual machine (i mean, the big process Java with all its threads is considered to the scheduling or each thread in particular is considered)?
    The depends on the implementation, the RTSJ doesn't explicitly address this. You could have a JVM that internally scheduled its own threads using a single native priority to position the VM with regards to other tasks on the system (which would be necessary to get determinism). But a true native threading implementation (which includes the RI, IBM's VM and Java RTS) will use OS priorities, and on Solaris and Linux (with real-time scheduling support) these priorities are system-wide, so threads are globally scheduled against all other tasks. In Solaris the real-time priorities sit above the system priorities but below interrupt priorities. On Linux you can assign any priority to any system task or interrupt (IRQ handler) - at least in theory, in practice it's a delicate balancing act: you need to make sure that an IRQ handler you depend on gets a chance to run (timer interrupt for example), but you need to be aware of latencies introduced by handlers you don't need (such as the block scheduler in the I/O subsystem).

    David