View Single Post
  #12   Spotlight this post!  
Unread 13-03-2011, 23:11
boomergeek's Avatar
boomergeek boomergeek is offline
Registered User
AKA: Mr. D (Dick DiPasquale)
FRC #0241 (Pinkerton Robotics)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Derry, NH
Posts: 191
boomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant future
Re: 706 had the curse of all curses

Quote:
Originally Posted by Ether View Post
Java (on Windows platforms) always runs the runnable thread with the highest priority. Lower priority threads run only if there are no runnable threads of higher priority. If there is more than one runnable thread at the same priority as the presently running thread, then Java (on Windows platforms) time-slices those threads to run them concurrently. I was wondering if anyone knows definitively if it works the same way on the cRIO with vxworks.

I don't have access to anything definitive about CRio, but all implementations of VXWorks I am familair with use "system ticks" and a preemptive kernel.

http://www.embeddedheaven.com/real-time-os-basics.htm

Preemptive kernels
In preemptive systems, the kernel schedules is called with a defined period, each tick. Each time it is called it checks if there is a ready-to-run thread which has a higher priority than the executing thread. If that is the case, the scheduler performs a context switch. This means that a thread can be preempted – forced to go from executing to ready state – at any point in the code, something that puts special demands on communication between threads and handling common resources.

Using a preemptive kernel solves the problem where a high priority thread has to wait for a lower priority thread to yield the processor. Instead, when the high priority thread becomes ready to run, the lower priority thread will become preempted, and the high priority thread can start to execute.

Most commercial RTOSes support preemption.
From this, you can expect that a running lower priority task will continue to run for up to a system tick even if other higher priority tasks become ready to run. (That is one reason why you have to be careful about not wasting processing time even in low priority tasks: it will have impacts on the how often the higher priority tasks get a chance to run, especially if the higher priority tasks make system calls that produce wait states very often within the high priority tasks.)
Reply With Quote