[RTEMS Project] #2365: Task pre-emption disable is broken due to pseudo ISR tasks

RTEMS trac trac at rtems.org
Fri Jun 12 12:12:15 UTC 2015


#2365: Task pre-emption disable is broken due to pseudo ISR tasks
-----------------------------+---------------------
 Reporter:  sebastian.huber  |       Owner:
     Type:  defect           |      Status:  new
 Priority:  lowest           |   Milestone:  4.11.1
Component:  cpukit           |     Version:  4.10
 Severity:  critical         |  Resolution:
 Keywords:                   |
-----------------------------+---------------------
Description changed by sebastian.huber:

Old description:

> We have for example:
>
> Scheduler_Void_or_thread _Scheduler_priority_Unblock (
>   const Scheduler_Control *scheduler,
>   Thread_Control          *the_thread
> )
> {
>   Scheduler_priority_Context *context =
>     _Scheduler_priority_Get_context( scheduler );
>   Scheduler_priority_Node *node = _Scheduler_priority_Thread_get_node(
> the_thread );
>
>   _Scheduler_priority_Ready_queue_enqueue(
>     &the_thread->Object.Node,
>     &node->Ready_queue,
>     &context->Bit_map
>   );
>
>   /* TODO: flash critical section? */
>
>   /*
>    *  If the thread that was unblocked is more important than the heir,
>    *  then we have a new heir.  This may or may not result in a
>    *  context switch.
>    *
>    *  Normal case:
>    *    If the current thread is preemptible, then we need to do
>    *    a context switch.
>    *  Pseudo-ISR case:
>    *    Even if the thread isn't preemptible, if the new heir is
>    *    a pseudo-ISR system task, we need to do a context switch.
>    */
>   if ( the_thread->current_priority < _Thread_Heir->current_priority ) {
>     _Scheduler_Update_heir(
>       the_thread,
>       the_thread->current_priority == PRIORITY_PSEUDO_ISR
>     );
>   }
>
>   SCHEDULER_RETURN_VOID_OR_NULL;
> }
>
> So the unblock event of a pseudo ISR task (MPCI or timer server) may pre-
> empt a task with disabled pre-emption.  Suppose a higher priority task
> than the non-preemptible task is ready.  Then this task gets scheduled
> once the pseudo ISR task blocks again.

New description:

 We have for example:

 {{{
 Scheduler_Void_or_thread _Scheduler_priority_Unblock (
   const Scheduler_Control *scheduler,
   Thread_Control          *the_thread
 )
 {
   Scheduler_priority_Context *context =
     _Scheduler_priority_Get_context( scheduler );
   Scheduler_priority_Node *node = _Scheduler_priority_Thread_get_node(
 the_thread );

   _Scheduler_priority_Ready_queue_enqueue(
     &the_thread->Object.Node,
     &node->Ready_queue,
     &context->Bit_map
   );

   /* TODO: flash critical section? */

   /*
    *  If the thread that was unblocked is more important than the heir,
    *  then we have a new heir.  This may or may not result in a
    *  context switch.
    *
    *  Normal case:
    *    If the current thread is preemptible, then we need to do
    *    a context switch.
    *  Pseudo-ISR case:
    *    Even if the thread isn't preemptible, if the new heir is
    *    a pseudo-ISR system task, we need to do a context switch.
    */
   if ( the_thread->current_priority < _Thread_Heir->current_priority ) {
     _Scheduler_Update_heir(
       the_thread,
       the_thread->current_priority == PRIORITY_PSEUDO_ISR
     );
   }

   SCHEDULER_RETURN_VOID_OR_NULL;
 }
 }}}

 So the unblock event of a pseudo ISR task (MPCI or timer server) may pre-
 empt a task with disabled pre-emption.  Suppose a higher priority task
 than the non-preemptible task is ready.  Then this task gets scheduled
 once the pseudo ISR task blocks again.

--

--
Ticket URL: <http://devel.rtems.org/ticket/2365#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list