[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettimeofday seconds rollover problem?
- Date: Mon, 27 Feb 2006 12:08:08 -0800
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: gettimeofday seconds rollover problem?
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
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
> 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.