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

[Joel Sherrill]

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.
>>>
>>> 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