View Single Post
  #12   Spotlight this post!  
Unread 09-08-2012, 21:01
Todd's Avatar
Todd Todd is offline
Software Engineer
FRC #1071 (Team Max)
Team Role: Mentor
 
Join Date: Feb 2005
Rookie Year: 2004
Location: Connecticut, Wolcott
Posts: 51
Todd is just really niceTodd is just really niceTodd is just really niceTodd is just really niceTodd is just really nice
Re: default behavior for thread overrun

In my workplace I've worked with VxWorks solutions where a task is spawned to act as a watchdog of other tasks, both for reporting purposes during development, and sometimes to ensure that a fault is raised in critical subsystems where the operator must be made aware of an equipment failure as soon as possible. This is usually done with some relatively trivial mutex trickery and a registry for how often every task should complete.

Like mentioned before, the VxWorks scheduler by default (the only iteration of it I've worked with, though I'm sure there are others) is a strictly priority driven system, where if task 1 has a higher priority than task 2, and is not asleep, then task 1 is running and task 2 is waiting, with no concept of 'high level' scheduling.

I think java has some more advanced java library scheduling implementations, but I'm not familiar with any of them beyond basic threads, and they may not all be supported on our hardware.

Labview, like Greg mentioned, is its own whole separate bear, but I think that a system like you're talking about could be implemented in any of the three, with varying amounts of effort.