Re: Interrupt Question

From: Steve Calfee (stevecalfee_at_hotmail.com)
Date: 02/25/05


Date: Thu, 24 Feb 2005 17:04:19 -0800

On Fri, 25 Feb 2005 00:01:15 GMT, no-one@dont-mail-me.com (Robert
Scott) wrote:

>On Fri, 25 Feb 2005 08:40:45 +1100, Mike Harding
><mike_harding@nixspam.fastmail.fm> wrote:
>
>>On Thu, 24 Feb 2005 15:14:02 -0500, "Adam Caruso"
>><Adam.Caruso@Marconi.com> wrote:
>>
>>>I recently encountered a problem, that I am having difficulty solving. Can
>>>any please shed some light on this topic?
>>>
>>>There is a hardware timer counter, which counts from 0 to 59. When it
>>>rollovers from 59 to 0 it will trigger an interrupt handler ISR1.
>>>
>>>TS=0;
>>>
>>>ISR1( ) ( will increase TS by 1).
>>>{
>>> #### A
>>> TS++;
>>>}
>>>
>>>There is another interrupt handler ISR2, which can happen at anytime and has
>>>a higher priority than ISR1. ISR2 will want to get the exact time from the
>>>TS value and also the value of the hardware counter.
>>>
>>>ISR2( )
>>>{
>>>

If the higher priority ISR2, which is caused by a higher priority but
unrelated event to isr1, can stand to be off by one ISR1 time, record
both the hardware timer and the TS counter. ISR1 must be able to shut
off ISR2 some way, because incrementing its counter TS and saving the
H/W is non-atomic. For instance with a "isr_disable" ISR1code
"isr_enable" sequence. Using this, ISR1 can never interrupt ISR2, and
ISR2 cannot interrupt ISR1 while it is updating the ram copy of TS and
the hardware register.

There are many inherently racy conditions. If you guarantee a winner
to all races that is ok. It is better to prevent the race and
guarantee atomicity of data.

Regards ~Steve