Shared Data Problem - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Shared Data Problem

Quoted text here. Click to load it

snip

Thanks Thad for those usefull ideas.

Ian
--
Ian Bell

Re: Shared Data Problem
Quoted text here. Click to load it
results

An alternative:
There is no problem when the ISR writes a variable whose size is equal
to the data bus length (word). In this case you can perform an atomic
read in a background task. (supposing no virtual memory)
There is a problem when the ISR updates two or more words. There you
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.


Re: Shared Data Problem
Quoted text here. Click to load it

That's fine as long as there is no need to indicate to the background that
there is new data. In that case the ISR also needs to set a flag (signal)
that there is new data. The background checks the flag and if there is new
data, reads it and *finally* resets the flag. Similarly the ISR needs to
check the flag before updating the data and reseting the flag. 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 pointers
instead of the flag.

Quoted text here. Click to load it

You need to take care not to start again too much but again a queue can
avoid this.

Ian

--
Ian Bell

Re: Shared Data Problem
Quoted text here. Click to load it
equal
atomic
that
(signal)
Quoted text here. Click to load it
is new
to

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.

Quoted text here. Click to load it
pointers

I agree with your solution, but it depends on the needs of the
application.
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.

Quoted text here. Click to load it
you
can

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.


Re: Shared Data Problem
Quoted text here. Click to load it

I like the counter solution. It means the background can detect if data is
lost rather than burden the ISR with this task and increase latency to
boot.


snip
Quoted text here. Click to load it

Yep, it is horses for courses as usual.

Ian

--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

If I am reading the nature of your question in the way I think you mean
then I was expecting better of you Ian. I would have thought you would know
that two processes/tasks writing to the same variable are bound to get
their collective knickers in a terrible twist. It would, surely, be better
to use separate variables and combine them elsewhere, out of reach of the
interrupt routine.

If this is part of a multi-processor system then you may have to sit down
and give some careful consideration to a proper dialogue between
processors. This may have to include some hardware handshaking as well.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem
<posted & mailed>


Quoted text here. Click to load it

Glad you think so highly of me ;-) though I am not sure I deserve it.

Quoted text here. Click to load it

Indeed I do know that and my question was what is the *current* thinking
about how to address the problem.

Quoted text here. Click to load it

You will have to explain how that solves the problem. *Any* code outside the
interrupt runs the risk that it may be interrupted as it operates on the
variable.

Quoted text here. Click to load it

I was thinking more of single processor systems.

Ian

--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

It is only because I have followed the postings you have made in the past
that I had come to form my opinion of your capabilities. Especially the
ones about development processes.

Quoted text here. Click to load it

I think, for the most part, Robert Scott has provided an overview that is
more or less in line with the current thinking. In High Integrity Systems
Development we would avoid situations where two tasks/processes would want
to update the same variable.
 
Quoted text here. Click to load it

In the situation where you want a total of operations by both the ISR and
the main task, incremementing a common variable would be very problematic.
It would be better to increment separate variables and, in the reporting
routine, disable interrupts while both variables are read and totalled.
 
Quoted text here. Click to load it
 
Noted.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem
<posted & mailed>


Quoted text here. Click to load it


Ah, now the development process is something I *do* know about.


snip
Quoted text here. Click to load it

Fine, I understand that now - yes that is a classic situation and disabling
interrupts is the classic solution. It's severe drawback is the inevitable
increase in interrupt latency. It surprises me no one has thought to tackle
this very basic issue at the hardware level - or maybe they have?

Ian



--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

The increased interrupt latency that results from disabling interrupts may
or may not be a "severe drawback."  In fact, a system that cannot stand having
it interrupts disabled for a few instruction cycle times is probably operating
too close to its performance edge to be reliable anyway.

Quoted text here. Click to load it

I readily imagine that there are specific examples of such hardware
solutions, but its hardly an unmanagable burden to disable interrupts
in the general case.
--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem

Quoted text here. Click to load it

That depends on the application.  For example, suppose the ISR in a
very simple system just toggles an output bit.  Further, suppose that
the application requires that the timing of that toggle be free of
jitter.  Such a system requires that the interrupts never be disabled,
even for a few instructions.  However, it is not operating close to
any performance edge and can be quite reliable.


-Robert Scott
 Ypsilanti, Michigan

Re: Shared Data Problem

Quoted text here. Click to load it

Precisely. The point is that interrupts provide the system responsiveness.
Disable them and and you compromise responsiveness. What's worse, every
book/article I have read simply talks about a global interrupt disable when
there is only one of them that may cause a problem. A less intrusive
solution is to just disable the *relevant* interrupt.

Ian

--
Ian Bell

Re: Shared Data Problem
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

This is much like the difference between monitors and other methods
such as semaphores.  It requires various software areas to have
intimate knowledge of other areas, which leads to mistakes and
maintenance problems.  In addition, the time involved in making
such a selective disable may well require system calls and be much
larger than that involved in the critical section.  A piece of code
that reads:

   oldstate = interrupts(off);
   value = shared.value;
   interrupts(oldstate);

A system such as the x86, where the interrupt enable is a bit in
the flags, can simply assemble:

   push flags
   di
   mov  value, protected
   pop  flags; /* thus restoring old state */

and neither is going to greatly affect system response, and they
don't care much about how other code segments use the interrupt
system.  A system using monitors will simply write:

   value = sharedmonitorvalue();

and be done with it.  The protection is up to the monitor, which
knows both where the value resides and how to most efficiently
protect it.

Similar things apply to setting the shared value.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem
Quoted text here. Click to load it
 snip


Agreed. It did not mean to suggest it as a viable alternative
--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

Certainly, and this is why one must ensure that one's hardware performance
holds this compromise to acceptable limits.

Quoted text here. Click to load it

This may very well be the result of attempts to describe the general case
rather than the capabilities of specific systems.

Quoted text here. Click to load it

Here we agree, as long as one's hardware supports the ability to do so.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem

Quoted text here. Click to load it


And one software performance too.

Quoted text here. Click to load it

Agreed.


Ditto.
--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

"Free of jitter" is an unachievable specification.  Instead, one should
specify acceptable levels of jitter in terms such as "variations in time
no greater than some period."

Quoted text here. Click to load it

Such a system had best include no other interupt sources, too, and there will
probably have to be no decision making involving the generation of the output,
but you did spec a "very simple system."

Quoted text here. Click to load it

Perhaps, but a system sufficiently simple to reflect your example is
probably a better candidate for a hardware-only solution rather than
a microprocessor.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
We've slightly trimmed the long signature. Click to see the full one.
Re: Shared Data Problem

Quoted text here. Click to load it


The example I cited is not hypothetical.  It is a real design that has
been produced and is providing variable duty-cycle PWM signals to
solenoids in an industrial test stand.  The processor is a PIC 12C671.
It converts an analog voltage command to a PWM duty cycle.  If I were
to do a hardware-only solution, then my single PIC would become an
oscillator with triangle-wave output and a comparator.  It would not
have any better performance, and would take up considerably more room
on the circuit board.


-Robert Scott
 Ypsilanti, Michigan

Re: Shared Data Problem

Quoted text here. Click to load it

Interesting. It is fairly easy to think of situations where disabling
interrupts can be problematic. Take a simple system that measures the
interval between successive interrupts by reading the value of a timer when
the interrupt occurs. This value may be passed to another task that
executes later to calculate the velocity but it is important the interrupt
is not delayed else the value passed will lead to inaccuracies.

Ian

--
Ian Bell

Re: Shared Data Problem

Quoted text here. Click to load it

There is always an element of uncertainty in any measurement (Heisenberg)
but we should always be able to evaluate the extent of that uncertainty. In
measuring the time between interrupts or generating minimal jitter
waveforms you will have to accept some level of jitter. I think that even
the Droitwich transmitter (198kHz) has a variance figure quoted somewhere
and that is used a reference in all kinds of measurements.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline