thread-safety of rtems_cpu_usage_report

[Joel Sherrill]

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.
> T.
>
>   
>>> -- Till
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mail
>>>   
>>>       
>>     
>
>   


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