Re: Shared Memory for Application/Communication decoupling

Boudewijn Dijkstra wrote:
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?

The fieldbus interface. I don't agree on your definition of an interface. In my opinion a interface is best described as a common boundary between two subsystems. It can be characterized by control properties(control signals), temporal properties(temporal constraints), functional intent(intended functions) and data properties(structure and semantics).

* 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 duplicated in the sense that when the computational task prepares
new values the previous values are still available (In the SHM). At the end of the computation the values in the shared memory are updated in an atomic way. Another approach would also require some double buffering because temporary values must not be communicated to a client.

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

Your point - But using the shared memory updates can be done in a small
step and if the time required for the updates is less than the time
required by the communication system consistency can be enforced. Using
message passing does not allow for fixed timepoints.


- 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?

A temporal firewall decouples the two systems from each other [1]. The
is currently a lot of research taking place on this and I have borrowed
this term from time trigged systems. This is beneficial for a system
because it limits error propagation. Of course checking inputs in the
value domain is still necessary (and complementary)

[1] ... http://www.omg.org/news/meetings/workshops/presentations/realtime_emb_presentations/RT_Session_3_Presentations/3-2%20Kopetz%20000725_OMG.pdf

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.

They can be truly cooperating in either way.

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.

For example assume there has to be done a big calculation in the
application task. First of all the values are subject to change and
therefore the temporary values can not be communicated to the
communication task. This implies that either

a) there must be a copy of recent (valid) values somewhere
b) the task must finish the calculation and then the new values can
be communicated.

a imposes the same memory overhead as shared memory and b ist not
suitable for our application.

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?

Different IPC mechanisms because of performance. Going with SHM because
of the benefits given above (in my opinion).

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.

Thanks a lot for sharing. Still I can't agree on this point because I
think the interface requirements are quite different. For example look
at other systems where different IPC mechanisms are used when
appropriate (EJB - Enterprise Java Beans with Locale and Remote
Interface to name only one). Maybe this would be a interesting poll for
the ESD magazine - ?Type of IPC mechanisms used today".

Kind regards,
Christian Walter
.

Relevant Pages

  • Re: Shared Memory for Application/Communication decoupling
    ... choosing a communication model between the application task and the communication task. ... Values must be consistent on the interface side at any time. ... At the end of the computation the values in the shared memory are updated in an atomic way. ... (For example at the end of the calculation if calibrations settings ...
    (comp.arch.embedded)
  • Re: Cisco PIX 501 Firewall
    ... 501's 4 port Switch then there is nothing to configure to enable ... If you see increasing CRC errors on the PIX's ethernet 1 interface ... it seems a problem in the communication between the PC and the ...
    (comp.dcom.sys.cisco)
  • Re: Cisco PIX 501 Firewall
    ... 501's 4 port Switch then there is nothing to configure to enable ... communication between the two. ... If you see increasing CRC errors on the PIX's ethernet 1 interface ...
    (comp.dcom.sys.cisco)
  • Re: Shared Memory for Application/Communication decoupling
    ... choosing a communication model between the application task and the communication task. ... Values must be consistent on the interface side at any time. ... At the end of the computation the values in the shared memory are updated in an atomic way. ...
    (comp.arch.embedded)
  • Re: Multicore programming - is that really hard?
    ... Inter-processor communication is cheaper, making multi-threading more efficient. ... coupled via pieces of shared memory; as well as so that cores are ... concurrent programming: forking, semaphores, and very much reduced ...
    (comp.programming.threads)