> On 27.05.22 11:49, gabriel.moy...@dlr.de wrote:
> >> On 27.05.22 10:51, Sebastian Huber wrote:
> >>> Hello Gabriel,
> >>>
> >>> the uniprocessor version uses an optimization at the reader side:
> >>>
> >>> #if defined(RTEMS_SMP)
> >>>       } while (gen == 0 || gen != th->th_generation); #else
> >>>       } while (gen != th->th_generation); #endif
> >>>
> >>> This is possible since the windup happens with interrupts disabled.
> >>> I guess you need this optimization somewhere in the PPS/NTP code.
> > Yes, you are right that is for the PPS code.
> > The value of th_generation is saved in pps_capture() and I shouldn't add a 
> > while waiting it to be different that 0 there.
> > If its value is 0, then the pps_event() returns early.
> > This is something that could happen in very particular circumstance (pps 
> > event happens when the th_generation is 0).
> 
> In uniprocessor configurations, we don't need the 0 special value. It is only 
> required in SMP configurations since one processor may
> observe a timecounter update which is in progress on another processor.

Being that case, the easiest solution will be to not check if pps->capgen == 0  
in pps_event() for uniprocessors configurations.

/* If the timecounter was wound up underneath us, bail out. */
#if defined(RTEMS_SMP)
        if (pps->capgen == 0 || pps->capgen !=
#else
        if (pps->capgen !=
#endif
            atomic_load_acq_int(&pps->capth->th_generation))
                return;

what do you think?

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to