Re: Shared Memory for Application/Communication decoupling

Op Thu, 07 Dec 2006 23:52:39 +0100 schreef Christian Walter <wolti@xxxxxx>:
We are currently evaluating design options and are in the problem of choosing a communication model between the application task and the communication task. The basic requirements are as following:

* The system should support different fieldbus protocol in the
future.
* The system must support Modbus RTU/TCP right now.
* Values must be consistent on the interface side at any time.

By definition, an interface lies _between_ value stores. What do you mean?

* All relevant data values must be communicated.
* Two-way communication must be possible. Reading on the fieldbus
side is more important.
* Lower bound for update of data on the interface side is 1 second.

We thought about using a Shared Memory Architecture between the two tasks which solves (In my opinion) the following problems:

- Handling consistency is easy because the data is essentially
duplicated.

I thought that "shared" meant that data is shared, i.e. not duplicated.

- It is easy to meet protocol deadlines because values can always
be read from the memory.

Either values can always be read from memory, or values are always consistent. Not both.

- The application task can take the values if it is ready for them.
(For example at the end of the calculation if calibrations settings
have changed).

What is the advantage here over other communication models?

- It works as a firewall (temporal) between the two tasks.

A firewall tries to prevent bad things from going past it in one or both directions. What are you trying to say here?

The other suggested way is using Message-Queues. The problem I see with them is that it is difficult to handle consistency

It depends.

and it also leads to a tight coupling in the time domain.

Yes, in the sense that they will be truly cooperating and not just doing their own thing with some shared data.

For example if the communication task needs a value the other task must supply it. What if the other task needs some values and the communication side wants to write them?

I don't see the problem here.

In this case we need some double-buffering again because otherwise the other task would work with inconsistent values.

What is your opinion on this issue? I would like to go with SHM but then we would need two different IPC mechanisms in the software.

Why?

Internally in the application task SHM would be too heavy and message queues (and of course simple function calls) are more appropriate. Does this violate system uniformity

Absolutely. ;)

(What is the correct English term for that) in the sense that one should not use different concepts for the same thing (IPC)?

Of course each IPC method brings in its own piece of code and using different IPC methods within a single task will introduce a lot of complexity.



--
Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
.