Re: Shared Memory for Application/Communication decoupling

Steve at fivetrees wrote:
"ChrisQuayle" <nospam@xxxxxxxxxxxx> wrote in message news:bLgeh.1064$KT2.493@xxxxxxxxxxxxxxxxxxxxxxx
Christian Walter wrote:

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
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'. If you have > 1 writer, you have to do all the synchronisation and mutual exclusion at low level, where it's difficult to maintian visibility and keep track of.

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.

*However* - if you're *really* stuck for memory, you might consider a block of shared memory as a part of the messaging interface - so long as you forbid your coders from bypassing the messaging interface on pain of death. Having distinct set/read routines is still essential.

BTW: I'm assuming that your comms code builds a mirror of the states of the remote controllers, and your application layer uses the mirrored data. If you interrogate on demand, then the memory issues go away - but the application is kinda slow...

Hello,

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


HTH,

Steve
http://www.fivetrees.com

Kind Regards,
Christian Walter



.

Relevant Pages

  • 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)
  • 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: [PATCH 1/6] staging: android: binder: Remove some funny && usage
    ... that Google used to test the performance of this interface. ... If Google believes the binder is the right solution for IPC, ...
    (Linux-Kernel)
  • Re: Newbie Needs Ada Advice
    ... in the filesystem and don't pass them through the RPC ... What you pass through the interface would just be the ... introduce the shared memory for explicit ... trust the file system cache of the machine to do the proper caching ...
    (comp.lang.ada)