Re: Shared Data Problem
From: Lanarcam (lanarcam1_at_yahoo.fr)
Date: 19 Mar 2005 11:05:11 -0800
Ian Bell wrote:
> Lanarcam wrote:
> > An alternative:
> > There is no problem when the ISR writes a variable whose size is
> > to the data bus length (word). In this case you can perform an
> > read in a background task. (supposing no virtual memory)
> That's fine as long as there is no need to indicate to the background
> there is new data. In that case the ISR also needs to set a flag
> that there is new data. The background checks the flag and if there
> data, reads it and *finally* resets the flag. Similarly the ISR needs
> check the flag before updating the data and reseting the flag.
A counter can be used to signal new data. the background task does not
need to modify the counter. This works of course if the background task
runs periodicaly or constantly. If the background task is suspended
you must signal new data by using a semaphore or an equivalent.
> This means the ISR can detect when data will be lost because the
> background has not
> read it. To avoid this you can use a queue with head and tail
> instead of the flag.
I agree with your solution, but it depends on the needs of the
If you must ensure no data is ever lost, the queue is necessary.
On the other hand if you have real time constraints, you must sometimes
read the most recent data. In this case you are better off without
a queue. Otherwise you need to time stamp your data.
> > There is a problem when the ISR updates two or more words. There
> > can devise a protocol, such as:
> > The ISR updates the data structure and then increments a counter
> > (word).
> > the background task reads the counter, reads the data structure and
> > reads the counter again.
> > If both readings of the counter yield the same result the operation
> > was successful. Otherwise start again.
> You need to take care not to start again too much but again a queue
> avoid this.
It depends on the timing of the interrupt. If the interrupt is
periodic you should need to start again once at most.
If the interrupt is sporadic the ISR must check for new data before
reenabling the interrupt. If interrupts occur too frequently the
system should be designed to take care of that.
Anyhow I agree again that a queue is unavoidable when the sequence
of data is critical. This is the case in data acquisition systems
such as RTUs. But for control equipment where timing is critical
you cannot use old data. In this case the sytem must be designed
in order to avoid tasks delays. Rate monotonic scheduling can be
used for that purpose.