Re: Shared Memory for Application/Communication decoupling

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

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.

[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


.

Relevant Pages

  • Re: Shared Memory for Application/Communication decoupling
    ... Shared memory / global data is a thing of the past, from the days when micros were not very powerfull... ... 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, ...). ... It is not possible that the communication task runs only when the currently calculated data has become stable because the calculation takes to long. ...
    (comp.arch.embedded)
  • Re: Shared Memory for Application/Communication decoupling
    ... different IPC methods within a single task will introduce a lot of complexity. ... Interface to name only one). ... shared memory techniques are just a nice way of saying 'global data'. ... You are right with that that this is 'global data'. ...
    (comp.arch.embedded)
  • Re: Shared Memory for Application/Communication decoupling
    ... different IPC methods within a single task will introduce a lot of complexity. ... Interface to name only one). ... I don't want to get into arguments about semantics, but in general, shared memory techniques are just a nice way of saying 'global data'. ...
    (comp.arch.embedded)