Re: Shared Memory for Application/Communication decoupling

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

HTH,

Steve
http://www.fivetrees.com


.

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: WriteProcessMemory
    ... WriteProcessMemory was designed to be used for debugging not ... IPC, and using it as an IPC mechanism is a bit unusual to say the ... The next closest thing are memory ...
    (microsoft.public.platformsdk.security)
  • Re: IPC
    ... Lisa Pearlson wrote: ... > Is IPC one particular method, with certain API's or is IPC just a general ... > terminology for any method of communication between two processes, ... > via shared memory or something? ...
    (microsoft.public.vc.mfc)
  • Re: IPC?
    ... SMe> applications? ... E.g how is IPC a solution to a lack of memory? ... dlls are loaded into gaps left after unloading bigger DLLs, ...
    (microsoft.public.windowsce.app.development)
  • Re: Jailed sysvipc implementation.
    ... +>> Some time ago I've implemented private memory zones for IPC mechism. ... +>> Every jail and main host got its own memory for IPC operations. ... I implemented something like allocate-on-demand. ...
    (freebsd-arch)