On Jun 2, 2014 9:18 AM, Gedare Bloom <ged...@rtems.org> wrote:
>
> >> @@ -200,27 +250,36 @@ RTEMS_INLINE_ROUTINE MRSP_Status _MRSP_Obtain(
> >> MRSP_Status status;
> >> const Scheduler_Control *scheduler = _Scheduler_Get( executing );
> >> uint32_t scheduler_index = _Scheduler_Get_index( scheduler );
> >> + Priority_Control initial_priority = executing->current_priority;
> >> Priority_Control ceiling_priority =
> >> _MRSP_Get_ceiling_priority( mrsp, scheduler_index );
> >> bool priority_ok = !_Scheduler_Is_priority_higher_than(
> >> scheduler,
> >> - executing->current_priority,
> >> + initial_priority,
> >> ceiling_priority
> >> );
> >> + Resource_Node *owner = _Resource_Get_owner( &mrsp->Resource );
> > I'd put this after the priority_ok check, for better readability by
> > keeping the error check closer to the cause. (Ahem, this should
> > probably be in our conventions too, eh?)
> >
> >>
> >> if ( !priority_ok) {
> >> return MRSP_INVALID_PRIORITY;
> >> }
> >>
> I guess I wasn't clear, I meant you should do owner =
> _Resource_Get_owner() here. e.g.
> -----
> Resource_Node *owner;
> bool priority_ok = !_Scheduler_Is_priority_higher_than(
> scheduler,
> initial_priority,
> ceiling_priority
> );
> if ( !priority_ok) {
> return MRSP_INVALID_PRIORITY;
> }
> owner = _Resource_Get_owner( &mrsp->Resource );
> -----
>
> Also, at one point in time we discussed about a rule of not having
> function calls in variable initialization. I will look if that is an
> actual convention or not, but it would make this code easier to read.
I personally find function calls in variable initialization a potential source
of undesirable side-effects.
Does this resource tracking replace the code for strict order mutex?
> -Gedare
> _______________________________________________
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
