gettimeofday seconds rollover problem?

[Till Straumann]

Last comments:

I assume IRQ disabled sections are short and
affected variables few. Performance is critical.

Thread-dispatch disabled sections are more
complex and catching all problematic accesses
is harder. Odds are that external subroutines
are called from such a section anyways.

Under these assumptions, I'd recommend to

a) use 'volatile' approach for IRQ disabled sections/variables
b) introduce a 'membarrier' to thread-dispatch disabling/enabling
    macros. It's still a good idea to explicitely declare volatile
    variables where appropriate.
d) don't know about the m68k/'cc' issue

-- Till

Eric Norum wrote:
> On Feb 27, 2006, at 10:18 AM, Joel Sherrill wrote:
> 
>>
>>
>> I liked the suggestion that the memory barriers be added to the ISR  
>> level wrappers not the
>> CPU specific implementations.
> 
> 
> Till has performance concerns about this.   I kind of agree that if  it 
> is sufficient that only volatile variables are modified inside a  
> disabled section then there's no real need to add the barriers.
> 
>>
>> You noted that cc needed to be added to the m68k which has to be  CPU 
>> dependent.
> 
> 
> I'm not sure that this is really necessary.  I don't think that the  
> compiler can really assume anything about the condition codes anyway.
> 
>>
>>> 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. :)
> 
> 
> The "if it is sufficient that only volatile variables are modified  
> inside a disabled section then there's no real need to add the  
> barriers" argument applies here, too.  Of course that assumes that we  
> figure out the exhaustive list of variables that need to be declared  
> volatile.  I think that Joel had a good start on this list.
>