[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettimeofday seconds rollover problem?
- Date: Fri, 24 Feb 2006 13:45:53 -0600
- From: norume at aps.anl.gov (Eric Norum)
- Subject: gettimeofday seconds rollover problem?
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
>>> 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