default behavior for thread overrun

[RyanCahoon]

Labview has its own worker queue system so I'm not sure how work is scheduled / where scheduling points are placed.

With the other two languages, I believe (pretty certain for C++, slightly less so for Java) that threads are mapped onto VxWorks threads (called tasks). From what I've read, VxWorks defaults to pure priority scheduling with round robin turned off, so the highest priority task that is ready to run at any given point is allowed to do so. So I guess I'm not sure what you mean by "overrun."

Since a task is ready to run unless it's either suspended, blocked on some resource, or delayed (by sleep() call, etc), then task ready state is only changed on either a system call or hardware interrupt (which would include a hardware timer for doing task sleep). System calls can only be triggered by the current running task, and control is shifted back to the kernel so that it may execute the system call. If it's a hardware interrupt, the processor will shift into an interrupt handler, which is part of the OS kernel, on the next instruction cycle.

Once the processor control has shifted to the kernel, the kernel saves off the register file state from the user task. At this point, it can either perform its necessary tasks and switch back to the same user task, or it can switch to a different task if the operation has caused a higher priority task to be ready to run. When the kernel switches back to a user task, it restores its register state and resumes from the point in the program where it had previously been.

So I guess the answer is (1)? If you let "allowed to finish" include "complete the currently executing instruction" in the case of a hardware interrupt event.




Disclaimer: this assumes that VxWorks and the PowerPC processor work roughly as taught in my embedded systems class... Otherwise, forgive my naivete