jcamerico wrote: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).
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)?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).