Chris Rose <rose_chris@excite.com> wrote:
Yes, it sounds like DLLs would work except that I thought the communication
to the hardware would be handled by Resource Managers (RM’s). I guess your
saying that each Subsys would use DLL’s to tell it which RM’s to use?
I generally use DLLs when I’m faced with some kind of runtime configurable
kind of thing, and I want to avoid the overhead of message passing. For example,
in my midi → wav synth, I’m putting the individual music synths into their
own DLLs, and having the main routine load them as required. It sounds like
you’d be doing something like that – having a common interface, and then
runtime loading the “personality” modules. An RM is certainly another way
to do that. Depends how much decoupling you want/need.
Cheers,
-RK
nospam93@parse.com> > wrote in message news:9vqs6a$7tl$> 1@inn.qnx.com> …
Chris Rose <> chris.rose@viasat.com> > wrote:
Let me see if I can explain this.
I designing a system that is comprised of several identical subsystems.
Each
subsystem is comprised of multiple processes. The reason for this
approach
is because to the client each subsystem will present the same interface.
However each subsystem may utilize different processes to work with
different hardware. i.e. Subsys A may get its data from a digital
transducer, while Subsys B get its data from an analog transducer, etc.
That part sounds like a job for DLLs…
The process that make up each subsystem will share data with each other
via
a shared memory dedicated to that subsystem. i.e. Subsys A will have a
shared memory area apart from Subsys B, and so on.
Now, the clients communicate with some elected “master” of the subsystem,
right?
If so, then the master would be responsible for starting up its
sub-processes.
The master creates the shared memory region, and can simply pass the name
of
the shared memory region on the command line to the newly created process.
So somehow when I start each process, I need to tell it whether it is a
constuent of Subsys A,B… That process would then come up and attach
itself
to the respective shared memory region. What is a good way to do this?
Does
shared memory have to register with procnto like a process has too?
Shared memory “registers” itself via “shm_open()” – in many respects,
it’s like a file, in that the OS keeps reference counts and so on.
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at > www.parse.com
Email my initials at parse dot com.
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.