thread-safety of rtems_cpu_usage_report

[Till Straumann]

Joel Sherrill wrote:
> Till Straumann wrote:
>> Joel Sherrill wrote:
>>  
>>> Till Straumann wrote:
>>>    
>>>> I look at rtems_cpu_usage_report() and it
>>>> seems to me that the code merrily scans
>>>> the _Objects_Information_table and accesses
>>>> the Thread_Control blocks it finds there
>>>> w/o using any kind of protection.
>>>>
>>>> What happens, e.g., if the _Objects_Information_table
>>>> gets extended or otherwise modified by another
>>>> thread while the code is scanning the table?
>>>>
>>>> Am I missing something?
>>>>         
>>> no. :(
>>>
>>> I had always wanted to change it to a loop
>>> from min to max id around a "get cpu use"
>>> task id based information call. Then it
>>> can fail on each one.
>>>
>>> But anything using iterate over all tasks is
>>> not thread safe. Perhaps it would be best
>>> to put that call in an allocation critical section.
>>> Then the set cannot change since there are
>>> no create/delete's allowed.
>>>     
>>
>> Definitely deserves some thought.
>> E.g., 'sync' looks quite a bit scary...
>>   
> I think using the allocation mutex would
> prevent any issues here also.  You wouldn't be
> able to malloc memory or create threads.
Which is why it's scary. Doing any I/O should
not delay malloc or thread creation.

T.
>> T.
>>
>>  
>>>> -- Till
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mail
>>>>         
>>>     
>>
>>   
>
>