gettimeofday seconds rollover problem?

Till Straumann strauman at
Fri Feb 24 19:24:38 UTC 2006

Eric Norum wrote:

> On Feb 24, 2006, at 11:36 AM, Till Straumann wrote:
>> Eric Norum wrote:
>>> 1) The _TOD_* variables must be declared as volatile since their   
>>> values can change in a fashion (Deus ex machina) not apparent to   
>>> compiler.
>>> 2) The M68K_BARRIER macro, or its equivalent addition to the  
>>> enable/ disable macros, is required to keep the optimizer from  
>>> hoisting/ sinking any code beyond the interrupt disable/enable  
>>> operations.   My  feeling is that it's clearer and simpler to just  
>>> add the "memory",  "cc" to the disable/enable macros, but I'm not  
>>> dogmatic about this.
>>> These two steps seem very clear to me since they impart to the   
>>> compiler exactly the information needed.  Both steps are necessary
>> This is not true. Only the 'volatile' declaration of global variables
>> that are accessed during any kind of 'inlined' protection mechanism
>> (be it interrupts, thread-dispatching, mutex, ...)  is necessary
>> (and sufficient).
> I'm not sure what you're trying to get across here.  It seems to me  
> that any global variable shared amongst threads (or amongst threads  
> and interrupt handlers) has to be declared volatile regardless of  
> whether it's accessed from inside an inlined protection mechanism or  
> accessed from anywhere else.

Not really. Usually you would use traditional 'mutex'es (or other 
synchronization primitives)
to guarantee consistency.
Only if the mutex take/release operations are inlined then you could 
face the
same problem (and that was my point).
Ultimately, however, the OS' sync. primitives do disable 
thread-dispatching and/or
interrupts so introducing a memory barrier there should be good enough.

IMO, the memory barrier is fine for thread-dispatch but I'm still a 
little bit sceptical
about introducing it to rtems_interrupt_disable/enable (especially on a 
RISC machine).


>> Nobody has addressed my point # 1: adding a memory barrier
>> to rtems_interrupt_disable/enable does not address thread-dispatch- 
>> disable
>> protected code. If we're going to add this safe-guard, it should
>> be introduced to thread_dispatch_disable/enable, too.
> Agreed.
>> BTW: I don't think we should modify all the ports! We should just
>>      change score/isr.h:
>>      #define _ISR_Disable( _level ) \
>>              _CPU_ISR_Disable( _level ) \
>>              asm volatile("":::"memory")
>>      #define _ISR_Enable( _level ) \
>>              asm volatile("":::"memory") \
>>              _CPU_ISR_Enable()
>>      #define _ISR_Flash( _level ) \
>>              asm volatile("":::"memory") \
>>              _CPU_ISR_Flash( _level ) \
>>              asm volatile("":::"memory")
>> _Thread_Disable_dispatch() should be treated alike.
>> -- Till
> Excellent solution!
> Who's going to commit this?

More information about the users mailing list