Re: Shared Memory for Application/Communication decoupling

Steve at fivetrees wrote:
"Christian Walter" <wolti@xxxxxx> wrote in message news:newscache$3we6aj$dbg$1@xxxxxxxxxxxxxx
Steve at fivetrees wrote:
"ChrisQuayle" <nospam@xxxxxxxxxxxx> wrote in message news:bLgeh.1064$KT2.493@xxxxxxxxxxxxxxxxxxxxxxx
A messaging based interface is generally more elegant and arguably more reliable, since for any single message, only one task writes and one task reads the data. This means that you can elevate syncronisation issues to a higher, task based level. Message based ipc reinforces an object view of the design at global level.

On modern micros, the overhead is probably insignificant as well. Shared memory / global data is a thing of the past, from the days when micros were not very powerfull...
I agree fully with Chris's remarks - I'd avoid global data like the plague.

However: I've also done fieldbus work, and I'm aware that one way of mirroring the states of the numerous parameters on numerous controllers is to use shared memory. I don't like this method myself - see above re global data. I much prefer a set of routines for accessing or changing parameter( PARAMETER_NAME ) on controller( index ). The usual arguments against this include a) different data types and b) overhead of the access methods - personally I prefer to solve these issues rather than fall back on global data. That way be dragons.

<snip>
Maybe I was not to clear on the intended function of the device. I am not doing a device which collects data. Its a measurement device and the discussion of shared memory came up because of the design issues I mentioned ( support different fieldbus protocols, temporal decoupling, ...).

Ah, I see. FWIW, this is even more familiar territory for me ;).

You say you're using a custom RTOS with no multitasking. If you're using a roundrobin or some other form of cooperative scheduling, you have synchronism right there. You can control the state the data is in before your application task yields. You can also ensure that all interrogable data is precalculated (or can be quickly precalculated from stable data).

Hello,

Yes - the OS we had was custom and used a non standard fieldbus protocol in the past. The old protocol did not set any requirements on the timing of the device. If the device was busy it only answered to special commands which where handled in an interrupt. Normal communication took place in the main loop where all calculations where performed.

Some time ago it was decided that we need to support additional fieldbus protocols and the project was limited in time and therefore most of the existing code base had to be used. The new protocol had timing requirements and we also needed to support reading values at any time. Therefore I worked on the operating system (C + 68k assembler) and added a preemptive multitasker together with some simple IPC primitives. This parts are finished and therefore at least theoretically available for a new design.

We are now in the need to support more devices in the feature and also have time and resources to rework and create bigger software components. In addition we want to move away from building our own OS ;). Maybe I could have told more about our already existing system but I think it is sometimes necessary to rethink old ideas. And I did not want to bias any of the opinions.

To put it another way, ensure that the comms task can only run when the data is stable and self-consistent. If this means building comms data packets on one pass through the loop, and buffering and transmission at a more leisurely pace either by interrupts or by polling, so be it. Similarly, for reception: when the application task runs, any comms-written data should be stable: it'll be able to react to (signalled) changes of data consistently, in one place. And you get your temporal decoupling [1] for free, or more specifically as a key part of the design.

It is not possible that the communication task runs only when the currently calculated data has become stable (which is calculated during automatic measurements) because the calculation takes to long (will also take a lot of time on a fast CPU). Therefore we introduced some buffering to communicate the values from the previous calculation. Of course I was a requirement that both tasks only work on consistent data. Updating is therefore always done in atomic blocks and at well known times.

I'd say again: use a messaging system, not global data. Use methods (and hence the opportunity to signal a query or a change) to access internal data. At the very least, ensure that your comms task knows nothing at all about the application task's data structure and use, and vice versa. I repeat: there be dragons.

Right now they are linked as separate modules and do not know anything from each other. The only share a common header file with SHM keys.

But as most people suggested a Message-Passing solutions I think I will go away from the SHM approach and use a message passing system with three tasks where one tasks acts as a coordinator. This matches my requirements, is clear from the design and using a new OS I can use the message passing primitives from there.

[1] If you mean as opposed to allowing both your comms task and your application task to read/write shared memory at will, which I can't believe you do. This would not even be a contender for a serious design.

HTH,

Steve
http://www.fivetrees.com



Kind regards,
Christian
.

Relevant Pages

  • Re: OT: Binary Search - Should They Know It?
    ... Considering you are having problems it would be advisable to design the app ... that the classes inside the DLL are unlikely to change but are reused ... Interfaces - This holds the interfaces for the data objects in the ... Our calculation engine is a monster. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: ID Frequently Unanswered Questions
    ... What is the scientific theory of Intelligent Design? ... What is Complex Specified Information? ... calculation as an example or illustration. ... Is there a lesson plan for teaching ID? ...
    (talk.origins)
  • Re: Shared Memory for Application/Communication decoupling
    ... object view of the design at global level. ... memory / global data is a thing of the past, ... discussion of shared memory came up because of the design issues I ... ensure that your comms task knows nothing at all ...
    (comp.arch.embedded)
  • Re: antennas
    ... on products that never saw the benefits of a calculation. ... Since we're talking about antennas, has anyone ever tried to model the ... reverse engineering a product? ... Answer: design and production ...
    (sci.electronics.design)
  • Re: Sum and product function in table
    ... principle of database design here. ... perform the calculation Do you see that the ... Open the Orders form in design view, and see how it picks up the ... > how do I enter the expression in the field of subtotal1 to give me the ...
    (microsoft.public.access.tablesdbdesign)