gettimeofday seconds rollover problem?

[Eric Norum]

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!

-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793