Thread: vxworks
View Single Post
  #4   Spotlight this post!  
Unread 25-03-2010, 15:15
wireties's Avatar
wireties wireties is offline
Principal Engineer
AKA: Keith Buchanan
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Rockwall, TX
Posts: 1,170
wireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond repute
Send a message via AIM to wireties
Re: vxworks

It is close, but not entirely correct in 2004 or now. There are 5 states:

pending - blocked forever waiting on a system resource
delayed - blocked for a number of system ticks
pending & delayed - blocked for a maximum number of system ticks waiting on a system resource
ready - ready to run
running - of all the ready tasks, the one picked by the scheduling algorithm to run - note that vxworks schedules tasks (w/o regard to which RTP or the kernel where the task resides), not processes

in addition there is a suspended shadow state correlating to the pening/delayed/pending&delayed/ready states - in other words vxworks keeps track of what state a pending task would be in if you resumed it

the version of vxworks we run supports threads (called tasks in vxworks) and processes (called real-time processes) - the FIRST examples run entirely in multiple tasks inside the kernel, they do not use RTPs and I'm not sure they are enabled - so all the FIRST code runs inside the same memory context (thus the code we run can whack other tasks and the kernel itself so be careful!)

Hope this helps