I am developing a software interface between two systems using Visual
C++ (microsoft). According to the specifications I will be writing a
series of independent processes (a total of 12, each responsible for a
certain functionality) that will interact among each other.
It was suggested to build each processes as threads. Each process
should be able to "talk" to any other process at any given time so
there will be the need for:
-- basic comunication functions (send message to other process,
receive message from other process)
-- an incoming message queue for concurrency
-- a way to identify each thread
These functions will be common to all processes since they will all be
structured in the same way, they will only differ for the
functionality they implement.
My question is:
I am looking for a library/resource that gives me these "containers"
that already have the inner comunication functionality, so I can just
replicate them and add the extra functions to meet my needs. |
Request for Question Clarification by
maniac-ga
on
01 Apr 2004 05:42 PST
Hello Goodwasabi,
Just a few comments on what you describe and then I'll ask for the clarifcation.
You appear to use processes and threads as equivalent terms. However,
a process (or application) has a memory space with one or more threads
of execution. So two processes will not share memory (unless you take
some specific action) but two threads will.
I will use the phrase "task" below to describe a chunk of work /
software that needs to be done (by a thread or process).
Do you want the two tasks to share memory or just the data being exchanged?
Do you want an error in one task to cause the entire application (all
tasks) to abort or just one?
Are you developing an application that may be migrated to Unix / Linux systems?
Answers to the first two will help determine if you should use threads
(or not). If the third answer is yes, it limits the solutions to
methods that work on both Windows and Linux. There are certainly a
number of good solutions to this type of problem - but please clarify
your situation so we get you the "right choice". For example, sockets
work good with communicating processes and is portable to both types
of systems, but has some overhead you might not be willing to absorb.
Thread safe queues can be used in threads but almost never work
between processes. [I can explain why if needed]
--Maniac
|
Clarification of Question by
goodwasabi-ga
on
01 Apr 2004 09:21 PST
Sorry for the misunderstanding.
I see no need to share memory.
All tasks should all be quite independent, I can't afford to make the
whole system sequential.
If one task encounters an error it will decide what action to take (if
to stop the other tasks or go on and ignore it).
I should be able to define what to do if a single task crashes, if the
crash will affect the whole system, the entire system should be
restarted but if I know that the task is not essential I should be
able to just restart it.
I see no need to port the program to Unix/Linux at this time, esp. if
it requires extra overhead. This program will have to be processor
efficient. It will be running on a computer that is already stressed
by another application that does PLC scanning, so I can't take up too
much processor time.
The idea of internal messaging+queuing was intended so that I would
have no concurrency issues, but maybe the same can be obtained if each
task exposes functions instead of accepting messages. When one task
wants to communicate with another they would just call the appropriate
function. Does this make sense?
|
Request for Question Clarification by
maniac-ga
on
01 Apr 2004 10:38 PST
Hello Goodwasabi,
>All tasks should all be quite independent, I can't afford to make the
>whole system sequential.
That is not a problem with either threads or processes.
>If one task encounters an error it will decide what action to take (if
>to stop the other tasks or go on and ignore it).
>
>I should be able to define what to do if a single task crashes, if the
>crash will affect the whole system, the entire system should be
>restarted but if I know that the task is not essential I should be
>able to just restart it.
If this is important - I would rule out threads. A thread crash (e.g.,
segmentation violation) would basically take out the whole process. If
you use separate processes, you have the opportunity to recover.
>I see no need to port the program to Unix/Linux at this time, esp. if
>it requires extra overhead. This program will have to be processor
>efficient. It will be running on a computer that is already stressed
>by another application that does PLC scanning, so I can't take up too
>much processor time.
I will keep the CPU load in mind.
Do you have any idea how much data will be passed around between the
tasks and the rates of transfer?
>The idea of internal messaging+queuing was intended so that I would
>have no concurrency issues, but maybe the same can be obtained if each
>task exposes functions instead of accepting messages. When one task
>wants to communicate with another they would just call the appropriate
>function. Does this make sense?
Yes it does - but if I was designing your system, I would encapsulate
the exchange of data or somehow manage the execution of tasks to limit
the scope of concurrency issues anyway. To explain the latter part
more fully - if you have a set of cyclic tasks, a simple architecture
is to gather the data [input phase], process the data [processing
phase], and then move the data to output buffers [output phase]. You
do not allow any task processing to start until all tasks have
completed their inputs, helping to prevent corruption of data.
I will be looking into some alternatives and get back later today.
--Maniac
|
,
0 Comments
)