[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettimeofday seconds rollover problem?
- Date: Mon, 27 Feb 2006 10:18:14 -0600
- From: joel.sherrill at oarcorp.com (Joel Sherrill)
- Subject: gettimeofday seconds rollover problem?
Eric Norum wrote:
> What's the current status of this?
Discussion stalled. Nothing committed AFAIK.
> 1) Have the 'volatile' additions to the _TOD_xxxxx variables been
> committed? I think that we all agree that this step is necessary.
I think we do all agree. Someone noted that any variable accessed and
between ISR Disable/Enable should also be volatile. By that logic, we
have more to add:
I think _Thread_Executing is OK since it only changes as a side-effect
of a subroutine call.
The contents of many chains change in ISRs so I think the fields in the
Chain_Control structures may need to be marked as volatile.
All of the above is based upon the statement that anything modified by
an ISR needs
to be volatile. Those are the most obviously critical items.
> 2) Are the "memory" barriers going to be added to the _ISR_Disable/
> Enable/Flash macros? If so, who's going to make and commit the
> changes? If not, are we sure that we are going to have correct code
> where they're used? It seems likely that any code protected by
> _ISR_Disable is going to be acting upon volatile variables but is it
> reasonable to assume that this will always force the compiler to
> generate the expected code?
I liked the suggestion that the memory barriers be added to the ISR
level wrappers not the
CPU specific implementations.
You noted that cc needed to be added to the m68k which has to be CPU
> 3) Are the "memory" barriers going to be added to the
> _Thread_Dispatch_disable/enable macros? If so, by whom and why do
> the arguments against adding the barriers to the interrupt macros not
> apply here as well?
I think the memory barriers need to be added to those macros given the
argument. We don't want something
moved outside any critical section so we need to draw our own Maginot
Line. I hope ours works well though. :)
> This problem is important enough that it needs to be dealt with quickly.
Yes. I just don't know that we reached a consensus. I ended Friday
with the impression that some volatiles
and memory barriers would resolve the problem. The cc issue on the m68k
implementation was orthogonal
to the real problem.
Unless you or Till objects, I would prefer to take the cross-platform
patches from one of you two. I know
you two have multiple hardware platforms to test on.
Any CPU dependent patches to ISR disable/enable code which has been
identified as a side-effect of this
discussion needs to come from a CPU expert.
What is the oldest GCC version, this behavior has been observed in? Can
we verify that it does or does
not occur in a version prior to that? I was specifically ask this
question by a user offline and want to see
what we all know. They were on a project which locked down an old RTEMS
with a gcc 2.95 variant.