code review: help implementing clock_montonic

Gedare Bloom gedare at rtems.org
Tue May 11 06:23:26 UTC 2021


On Fri, May 7, 2021 at 12:53 PM zack_on_the_speed_chanel
<zack_on_the_speed_chanel at protonmail.ch> wrote:
>
> hello,
>
> Currenttly i'm trying to implement the clock_monotonic which was part of  ticket #3889. So far these are the changes are as follows
>
This ticket mostly references the need for a test. Have you tried to
write a test for the missing functionality?

> ptimer->clock_type= &clock_id;
> in the timer create i added a field for the timer id and saved it when the timer was made. Then in getttime I used the appropriate timers to get the time.
>
> for example.
>
>   if (ptimer->clock_type ==CLOCK_REALTIME) {
>     Per_CPU_Control *cpu;
>      struct timespec spec;
>      struct timespec expire;
>
>     cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );

Maybe move the clock_type check to here?
>     _TOD_Get(spec);
>       _Timespec_From_ticks( expire, &ptimer->Timer.expire);
>
>
>     if (spec->tv.nsec+spec->tv.sec > expire->tv.nsec+expire->tv.sec ) {
>
>       remaining = (uint32_t) (expire->tv.nsec+expire->tv.sec  - spec->tv.nsec+spec->tv.sec);
this math doesn't make sense to me. explain what you're trying to do?

>     } else {
>       remaining = 0;
>     }
>
>     _Timespec_From_ticks( remaining, &value->it_value );
>     value->it_interval = ptimer->timer_data.it_interval;
>
>     _POSIX_Timer_Release( cpu, &lock_context );
>     return 0;
>   }
> Here i made two separate cases  for getting the time. Also joel told me to I feel that it is a bit redundant to call everything using timespec to calculating remaining time and then just use  timespec_From_ticks to get the time. It was a recommendation from  Joel. Did I make the correct change. Also I assume that Delete does not need any changes because It does not require any measuring of time. Is there anything i need to change for timer_settime?
>
Yes, settime is an important function to distinguish between MONOTONIC
and REALTIME cases. That is going to be tricky to think through.

> Thanks
> Zack
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list