disabling interrupts

[gregory.menke at gsfc.nasa.gov]

 > > 
 > > Does disabling Interrupts also prevent a task switch from occurring?
 > > 
 > 
 > No.
 > 

If a task goes to sleep (via blocking read for instance), another task
can be scheduled.  If no other user tasks are schedulable, the idle
task runs.  If your tasks are created with preemption disabled, this
is the sole method by which multitasking occurs.

On some bsps you can supply a thread-specific set of enabled
interrupts, which means each task can enable a particular set of
interrupts & the task switching code will impose each thread's enables
as it is scheduled in.  Usually each task is created with all
interrupts enabled & quiet.

If you get into hacking at your bsp, the context switching code can be
a little confusing.  Essentially, if a task blocks & is scheduled out,
it will be doing so in a library call; user code never blocks itself
only via a call to the C lib or RTEMS.  When the task is scheduled
back in, it will simply return from the call.  If a task is preempted,
it will be via an interrupt (usually the timer tick)- and when it is
scheduled back in, the task resumes executing by simulating a return
from the interrupt- even if the previous task was scheduled out by
going to sleep.  Making this work leads to fairly subtle trickery with
the cpu context & stack- nothing very exotic but it has to be exactly
right.

Gregm