Shared Data Problem

Many thanks for the comprehensive examples.

ian

--
Ian Bell
Reply to
Ian Bell
Loading thread data ...

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.

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.

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.

Noted.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

I am just speculating. I don't think algorithms are more powerful or complex. The volume of work has gone up in many cases because of pure laziness. This is especially evident in the C++ world of templates. It is cheap and cost effective to throw another megabyte of storage at the thing. The machine is now fast enough to scan through that and pick up the few items we really want. And so on.

--
"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 
 Click to see the full signature
Reply to
CBFalconer

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

snip

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
Reply to
Ian Bell

I was thinking particularly of the move from analogue to digital systems where complex encoding/decoding is commonplace (MP3, GSM et al)for example whereas 10 years ago they were rare (apart perhaps from Reed Solomon decoding in CD players).

Ian

--
Ian Bell
Reply to
Ian Bell

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.

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
 Click to see the full signature
Reply to
Michael R. Kesti

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

Reply to
Robert Scott

... snip ...

They certainly have. What do you think the FIFO buffer in your RS232 UART chip is doing?

--
"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 
 Click to see the full signature
Reply to
CBFalconer

They do, by making timers longer in HW, for example, or by adding Dual port memory/FIFOs/DMA on the peripherals, or even by adding an IO co-processor, so that the main cpu is insulated from the hard-real-time stuff.

-jg

Reply to
Jim Granville

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
Reply to
Ian Bell

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
Reply to
Ian Bell

I know what you mean about IO specific aids like FIFOs but I was thinking of something more generic actually within the interrupt hardware itself.

Ian

--
Ian Bell
Reply to
Ian Bell

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.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

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.

Reply to
Lanarcam

Indeed, and as engineers we seek to minimise uncertainty.

Ian

--
Ian Bell
Reply to
Ian Bell

... snip ...

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 
 Click to see the full signature
Reply to
CBFalconer

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.

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

Ian

--
Ian Bell
Reply to
Ian Bell

snip

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

--
Ian Bell
Reply to
Ian Bell

equal

atomic

that

(signal)

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.

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.

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.

Reply to
Lanarcam

"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."

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."

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
 Click to see the full signature
Reply to
Michael R. Kesti

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.