> 2. Race Conditions.
>         If your low priority processes use shared variables that are also
> accessed by high priority processes the arbitrary interruption can cause
> race conditions.
>         EXAMPLE -- Highly contrived
> C Code
> Process A                       Process B
>         i++;                            i++;
>
> Assembler
>         movf i
>                 ---->INTERRUPT-->       movf i
>                                         addlw 1
>                                         movwf i
>                 <---RETURN<-----
>         addlw 1
>         movwf i

I have a difficult situation like this now.  The interrupt routine needs to
update some real time data.  Every 4 seconds it writes two arrays of 16
float variables.  It takes the isr 150 ms to calculate and write the arrays.

The main routine takes copies of these arrays, and runs for 5-15 seconds
calculating secondary display items based on the data at that moment in
time.

If I have the isr set a semaphore saying that it is updating the arrays,
then main can wait.  But if main is making the copy, and the interrupt
fires, the arrays will have part old and part new data.

I can't tell the isr not to update, because this data is what the app is all
about.  If I turn off interrupts, I introduce 66ms of latency during the
copy of the arrays.  That takes a lot of time from the isr to do the things
it needs to do.

If I create some sort of "write in progress" flag, it will be set and
cleared without main seeing it.

A "new data available" flag doesn't prevent the isr from updating it while
main is in the process of copying.

Since main is not time sensitive, I don't mind having it to recopy if it got
a bad copy, but I don't know how to let it know.

Making two copies and comparing them is one way, I suppose.  Keep doing that
until I get two identical copies.  But its not very elegant, and it uses a
big chunk of memory that is tight already.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.543 / Virus Database: 337 - Release Date: 11/21/2003

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body