Writing code that takes time to run

[Richi Dubey]

Hi,

About the code:

 T_busy(T_get_one_clock_tick_busy() * SOME_CONSTANT);

does this support context switch? If task A executing on CPU 1 gets
preempted while executing this (by task B) and then comes back on CPU 1
after some time (when task B finishes its execution), would task A finish
its execution of this function - as nothing happened?

So, if we ask Task A to run T_busy for 5000 ticks, and it gets preempted
after 3000 ticks and maybe moves to another CPU, would it run for the
remaining 2000 ticks on that CPU?

On Fri, May 21, 2021 at 9:50 AM Richi Dubey <richidubey at gmail.com> wrote:

> Hi,
>
> Thanks for your quick responses!
>
> The suggestion certainly is helpful, we are going to try it out. I'll post
> the result here.
>
> On Thu, May 20, 2021 at 8:57 PM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Thu, May 20, 2021 at 10:05 AM <Jan.Sommer at dlr.de> wrote:
>>
>>> Hi Richi,
>>>
>>>
>>>
>>> You can checkout the T_busy functions here:
>>> https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390
>>>
>>> uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count
>>> for one tick.
>>>
>>>
>>>
>>> You can then calculate the number of cycles you need to wait for you
>>> desired certain time and pass it to: void T_busy(uint_fast32_t)
>>>
>>> This should give you comparably accurate results over different
>>> platforms.
>>>
>>
>> That's certainly a better method than what I suggested.
>>
>> --joel
>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>>     Jan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* devel <devel-bounces at rtems.org> *On Behalf Of *Richi Dubey
>>> *Sent:* Thursday, May 20, 2021 4:53 PM
>>> *To:* rtems-devel at rtems.org <devel at rtems.org>
>>> *Subject:* Writing code that takes time to run
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> We are thinking of writing a piece of code that takes some time to run
>>> (it would be amazing if it takes around 2 secs to run on hardware, but we
>>> would be happy with something that takes a few milliseconds as well).
>>>
>>>
>>>
>>> We tried writing this:
>>>
>>>
>>>
>>>   for(int i = 0; i<10000000; ++i){
>>>       fib2 = fib0 + fib1;
>>>       fib0 = fib1;
>>>       fib1 = fib2;
>>>   }
>>>
>>>
>>>
>>> which takes few milliseconds when tested on qemu, but only takes few
>>> microseconds on a real board. Do you have any suggestions of what else we
>>> can do?
>>>
>>>
>>>
>>> We want to write a code that is context switch safe (so, we can't simply
>>> check the time before a loop, run an infinite loop that keeps checking
>>> current time and stops after a few seconds - because this logic would fail
>>> if there happens a context switch inside the loop and the task gets the
>>> control back after a few seconds). We also don't want to do a wake_after()
>>> since we want the task to be running on the cpu during the entire time (it
>>> is okay if the task gets preempted due to a higher priority process), and
>>> not voluntarily giving the control to some other task.
>>>
>>>
>>>
>>> Any suggestions? The aim is to see the affect of a task getting removed
>>> from the cpu due to task shifting by the newly arrived task (in strong apa
>>> vs non task shifting scheduler).
>>>
>>>
>>>
>>> Thank you.
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210522/e1ee0c2a/attachment-0001.html>