Priority aggregation question

Malte Münch mamu at stablerock.de
Thu Feb 28 08:55:57 UTC 2019


Hello,

i am currently playing around with resource sharing protocols and have a
question regarding the priority aggregation behaviour of RTEMS. I have
to tasks both with a "base" priority of 10. I set that priority via:

rtems_task_set_scheduler(task1, sched0, 10);

Later i am raising the priority via this code (mainly copied from
_MRSP_Raise):

  ISR_lock_Context         lock_context;
  Priority_Node            *priority_node;
  Priority_Control         new_prio;
  new_prio = 5;

  priority_node = &(fmlpl->Ceiling_priority);
  thread = _FMLPL_Get_owner(fmlpl);
  _Thread_queue_Context_clear_priority_updates( queue_context );
  _Thread_Wait_acquire_default_critical( thread, &lock_context );
  _Priority_Node_initialize(priority_node, new_prio);
  _Thread_Priority_add(thread, priority_node, queue_context);
  _Thread_Wait_release_default_critical( thread, &lock_context );


I am printing the current aggregated priority to the terminal via:

rtems_task_get_priority(id, sched, &rtp);

Before the execution of the priority raising it prints a 10 (which is
what i expected) and after the execution it prints a 2. I expected a 5
to be printed because the documentation says:

The overall priority of the aggregation is the minimum priority of the
priority nodes in the contributors tree.
(https://docs.rtems.org/doxygen/branches/master/structPriority__Aggregation.html#a98e1d7eb856737a9fafb3d0302b5db9e)

I dont know if it is important but the task that triggers the priority
raise is on a different scheduler (and cpu) than the task which gets the
updated priority.

thanks for any answer/explanation in advance.

Best regards
Malte


More information about the devel mailing list