gettimeofday seconds rollover problem?
joel.sherrill at oarcorp.com
Mon Feb 27 17:44:52 UTC 2006
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.
I agree. If volatile is sufficient, then I don't want to do anything
>> 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.
Then let's ignore this one for now.
>>> 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.
Can those who have been looking at the generated code try volatile on
the list of variables I proposed?
If that's enough, it is a pretty mild patch.
More information about the users