Re: Shared Memory for Application/Communication decoupling

ChrisQuayle wrote:
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


Hello,

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.

You are right with that that this is 'global data'. But I don't see the difficulty for maintenance in this design. Basically I would introduce the following rules for both tasks (Let us assume our deadlines are 100ms).

* No task must lock the shared memory for read/write updates for more
than 25ms.
* Values which must be consistent must be updated in one block.

At the lower level I would have Lock, Get, Put and Unlock functions where Get and Put could also support automatic locking to ease up things for programmers.

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.

A point against the message based interfaces is that if directly used there is a temporal coupling between the two tasks which must be avoided. Using message passing only to transfer new values and then buffering the data at the communication task provides the same benefits as the shared memory approach (consistency + decoupling) but has the same overhead.

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

In what case is a filesystem different in your opinion than a shared memory? In that case I would also be wrong to use files to exchange data between applications.
Of course using global data between modules and at the interface level is bad because there are a lot of problems with reentrancy and consistency. But applying shared/distributed memory as a design pattern for specific problems is still valuable.


Regards,

Chris


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). ... 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
    ... 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)
  • "System V IPC is a botch?"
    ... immediately used to access a message queue, semaphore set, or shared memory ... With Sys V IPC, B can ... Does not fit comfortably within the "traditional unix filesystem ... > threaded process to block on multiple message queues. ...
    (comp.unix.programmer)
  • Re: Shared Memory for Application/Communication decoupling
    ... different IPC methods within a single task will introduce a lot of ... memory techniques are just a nice way of saying 'global data'. ... A messaging based interface is generally more elegant and arguably more ...
    (comp.arch.embedded)
  • Re: WriteProcessMemory and ReadProcessMemory
    ... In addition to Administrators, developers also need debug privilege, but you ... WriteProcessMemory/ReadProcessMemory for IPC is simplicity for the ... > If you want to use the memory for IPC communication than use SHARED MEMORY ... > access) but it doesn't have the security risk of touching the other ...
    (microsoft.public.platformsdk.security)