Need advice

Hi,

I need to get some advice from you to find out a good
way to handle this.

  1. I have an inproc and it is using memory map.
  2. This inproc can be loaded by different processes.
    They will share the same memory map.
  3. When one of the process changes certain items in
    the memory map, other processes should be notified.
  4. Other processes need to know exactly what has been
    changed and take the corresponding action.

One way to do that is all the processes wait for a
certain event, when the memory map is updated, then
the event is set and each process can take a look in
the memory map to see what happened, … The problem
with this is there are quite a lot of items in the
memory, and it is not efficient for each process to
scan the memory map to find out what happened.

The other way I can think of is we can put the action
inside the memory map, probably that needs to be a
queue. Then each process can take a look the queue and
see what happened. The problem with that is now we
need to have a description for each activity and it is
not very easy to do that either.

Based on these information, can somebody give me some
advice.

Thanks in advance.

G.C.


Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

>1. I have an inproc and it is using memory map.

  1. This inproc can be loaded by different processes.
    They will share the same memory map.
  2. When one of the process changes certain items in
    the memory map, other processes should be notified.
  3. Other processes need to know exactly what has been
    changed and take the corresponding action.

Your aware this strategy will mean any of these processes can corrupt the
shared memory, and potentially bring down all the other processes using the
same inproc? You also aware the mapping address in each process may not be
the same?

You ever consider having the shared data structure live in it’s own
process? You might also come up with a variant where the shared data is
normally not directly accessible from a process (in it’s own process), but
can be mapped in for “heavy duty” operations. Having the data in a
different process may actually perform better, as you will not need to use
base relative addressing for everything (it depends on your problem if the
overhead of crossing process boundaries for the interfaces will exceed the
gains from direct addressing).

My personal preference would probably be to keep the shared data in it’s
own process, accessed through well defined transactional interfaces. If
performance then was a problem, find the bottlenecks. The opposite is to
pre-optimize things, and potentially later deal with insufficient
stability/reliability. Offhand, I know of much better tools to find
performance problems than stability problems.

Security is also hugely better with the data in it’s own process. If
everything is mapped in all the processes, there is essentially no
security. By controlling which processes get interfaces, you can carefully
control who can do what.

  • Jan

> Based on these information, can somebody give me some

advice.

Is the number of “listening” processes limited?
If yes - you can maintain a per-process “dirty” bitmap (1 bit per item) -
the
updating process sets the appropriate bit in all other processes’ bitmaps
and
signals the event. The listening process scans the bitmap and determines
what to do.
If no - then the queue of updates seems to be the best idea.

Max