gettimeofday seconds rollover problem?

[Till Straumann]

Eric Norum wrote:

> On Feb 24, 2006, at 1:24 PM, Till Straumann wrote:
>
>> 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).
>
>
> My concern was not so much about consistency as it was about the  
> compiler adjusting or removing access to a global variable because  
> the compiler "knows" from its view of the flow of control that some  
> section of code does not affect the variable's value.
> You're right that the presence of inline operations makes this more  
> likely -- but the compiler seems to be getting quite aggressive when  
> it comes to inlining almost anything now!


It can never move access to a globally visible variable across a 
function defined in a separate
compilation unit.

T.