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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
