AW: AW: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

Gabriel.Moyano at dlr.de Gabriel.Moyano at dlr.de
Mon May 30 06:29:43 UTC 2022


> On 27.05.22 11:49, Gabriel.Moyano at 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?



More information about the devel mailing list