rtems_xxxx_ident() does not support global search for all objects in the classic API

[Andrei Dimitrief-Jianu]

On Tue, Oct 9, 2012 at 7:48 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> On 10/9/2012 5:59 PM, Andrei Dimitrief-Jianu wrote:
>>
>> On Tue, Oct 9, 2012 at 6:36 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
>> wrote:
>>>
>>> On 10/9/2012 4:47 PM, Andrei Dimitrief-Jianu wrote:
>>>>
>>>> Hello,
>>>>
>>>> Below are two different implementations for rtems_xxxx_ident()
>>>> directive, one for semaphores and the second for barriers.
>>>>
>>>> rtems_status_code rtems_semaphore_ident(
>>>>     rtems_name  name,
>>>>     uint32_t    node,
>>>>     rtems_id   *id
>>>> )
>>>> {
>>>>     Objects_Name_or_id_lookup_errors  status;
>>>>
>>>>     status = _Objects_Name_to_id_u32( &_Semaphore_Information, name,
>>>> node,
>>>> id );
>>>>
>>>>     return _Status_Object_name_errors_to_status[ status ];
>>>> }
>>>>
>>>> rtems_status_code rtems_barrier_ident(
>>>>     rtems_name  name,
>>>>     rtems_id   *id
>>>> )
>>>> {
>>>>     Objects_Name_or_id_lookup_errors  status;
>>>>
>>>>     status = _Objects_Name_to_id_u32( &_Barrier_Information, name,
>>>> OBJECTS_SEARCH_LOCAL_NODE, id );
>>>>
>>>>     return _Status_Object_name_errors_to_status[ status ];
>>>> }
>>>>
>>>> Anyone can explain why for barriers the search is done only on the
>>>> local node? Was it simply an implementation choice? Any other reason
>>>> for that?
>>>
>>> It is much simpler than you think. If the Object Class supports remote
>>> operations
>>> (e.g., global attribute on create and helpers internally), then it has
>>> the
>>> three argument
>>> form. Otherwise it takes the two argument form.
>>>
>>> Timers and Rate Monotonic Periods are strictly local. Two argument form.
>>>
>>> Barriers COULD be global but don't implement that so they use the two
>>> argument form.
>>>
>>> In general terms, only the objects originally required to be global by
>>> the
>>> RTEID/ORKID specification support global operations. The development and
>>> testing effort has never been put into adding global support on more
>>> recent
>>> Object classes even when it logically could make sense to support it.
>>
>> That makes sense.
>>
>> What I would like to ask is: would it make sense for an event flag
>> manager to support
>> global operations?
>>
> It would make sense just as it would make sense for a barrier to support
> them
> but if no user has a requirement for them to be global, I tend to lean to
> not
> implementing them.
>
> There are some scenarios that need to be considered for a free standing
> Event
> Manager. I was talking to someone here at OAR about trying to remember all
> the odd cases we came up with when we implemented this for a customer
> in that distributed middleware I sent you a link to a presentation on.
>
> Some that come to mind are
>
> + Does it make sense for tasks to block in priority order?
>
> + T1 (first task on queue) is waiting on Event 1 and 3.
>    T2 (second task on queue) is waiting on Event 3
>    T3 sends Event 3
>    What happens? Does T2 stay blocked until T1 is unblocked?
>    If so, does it also receive EV3? Or does it need to be sent again
>
> + T1 (first task on queue) is waiting on Event 1 and 3.
>    T2 (second task on queue) is waiting on Event 2
>    T3 sends Event 2
>    What happens? Does T2 wake up now or after T1 is unblocked?
>
> + Consider impact of first task on queue timing out. Does
>    the head of the queue have to be reevaluated?
>
> Please capture these scenarios as we think of them. The behavior
> has a lot of options and I am not sure which are desirable in
> real life. We also have to stay practical and avoid O(n) situations.
>

I think there should be the option of having the tasks waiting in
priority order (FIFO would be the default).

All tasks waiting for a certain event will be notified when the event
is posted. The order on the waiting
queue tells the event flag how to evaluate the tasks that are blocked.

+ T1 (first task on queue) is waiting on Event 1 and 3.
   T2 (second task on queue) is waiting on Event 3
   T3 sends Event 3

In this case T1 receives E3 and remains blocked waiting for E1 while
T2 is released.
T1 was waiting for E1 and E3, and it should not have to be sent E3 again.

+ T1 (first task on queue) is waiting on Event 1 and 3.
   T2 (second task on queue) is waiting on Event 2
   T3 sends Event 2

T2 wake up and T1 stays blocked until it receives E1 and E3.


Regards,
Andrei.

>>>>
>>>> Thanks!
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>