I have a quick question. Not really a QNX question but more of a design
question.
For designing software on the QNX RTOS, is it better to have a
multi-threaded program or a multi-process program. What are the advantages
and disadvantages to either?
Sorry for the loaded question, but I’m just looking for everyone’s opinion
Thanks,
Phil
Phil <felipe.marcelino@sippican.com> wrote:
I have a quick question. Not really a QNX question but more of a design
question.For designing software on the QNX RTOS, is it better to have a
multi-threaded program or a multi-process program. What are the advantages
and disadvantages to either?Sorry for the loaded question, but I’m just looking for everyone’s opinion
You sure know how to pick them! 
Generally speaking, if the “tasks” in question are all performing related
work, then you might lean towards threads. If they are doing something
totally different, then you’ll want to lean towards processes.
Threads give you implicit memory sharing, which may or may not be a good
thing. Processes give you memory protection, which, in general, is a
good thing. YMMV.
To properly answer the question, though, more information is needed…
Cheers,
-RK
–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/
Phil wrote:
I have a quick question. Not really a QNX question but more of a design
question.For designing software on the QNX RTOS, is it better to have a
multi-threaded program or a multi-process program. What are the advantages
and disadvantages to either?
Simple answer:
Threads:
Advantages Disadvantages
-Easy access to shared state - Easy access to unshared state
-Less resource intensive
Processes:
Advantages Disadvantages
-Difficult access to unshared state - Less easy access to shared state
At first glance threads may appear to have the edge, but each of these
advantages/disadvantages should be weighted when it actually comes to
considering design for testability (which really should be a primary goal of
every software engineer). It just so happens that “easy access to unshared
state” and “difficult access to unshared state” are both weighted heavily when
it comes to testability (aka bug reproducability). This means that initially
processes get a big win in the advantages column, and threads get a big loss in
the disadvantages column.
If you are doing a deeply embedded system where all resources are highly
constrained, the “less resource intensive” attribute may get weighted
sufficiently heavily that it makes up for the “easy access to unshared state”
attribute in the negative column. This means that deeply embedded systems are
more difficult to test, but it’s worth it (figuring out whether it is worth
it is a project wide decision on an embedded system since it involves all sorts
of costing and market timing issues).
If you are doing something that requires high performance with a lot of shared
state, then both the “easy access to shared state” and “less resource intensive”
attributes may combine to exceed the “easy access to unshared state” in the
negative column.
The majority of application components do not fall into either of these
categories, a fairly common application component that does fall into the second
category (in QNX) is a resource manager for a “performance critical path” shared
hardware resource (e.g. disk I/O subsystem, network subsystem, etc.).
PS: Of course, the issue is more complex than can be stated in 5 paragraphs,
however, this is the most concise guideline I can come up with that addresses
the primary differentiating factors between threads and processes. Hope this helps.
Rennie
“Phil” <felipe.marcelino@sippican.com> wrote in message
news:c2sii8$36d$1@inn.qnx.com…
I have a quick question. Not really a QNX question but more of a design
question.For designing software on the QNX RTOS, is it better to have a
multi-threaded program or a multi-process program. What are the
advantages
and disadvantages to either?Sorry for the loaded question, but I’m just looking for everyone’s opinion
I always try to use processes and then only if I can gain something
significant I will use threads.
Threads increases complexity, they are harder to debug, harder to identify
amongts each other (pidin will not tell you witch thread is witch) If one
thread crashes the whole process crashes.
With processes you are force to be modular. Easier on the build
environment; you don’t have to relink everything just the program you are
working in. Much easier if you are in a multi developper environment.
Easier to build unit test and perform testing in general (each program can
have it own test setup).
Thanks,
Phil
just my 1 cent - switching between threads is much faster then between
tasks.
cheers,
Igor
“Phil” <felipe.marcelino@sippican.com> wrote in message
news:c2sii8$36d$1@inn.qnx.com…
I have a quick question. Not really a QNX question but more of a design
question.For designing software on the QNX RTOS, is it better to have a
multi-threaded program or a multi-process program. What are the
advantages
and disadvantages to either?Sorry for the loaded question, but I’m just looking for everyone’s opinion
Thanks,
Phil
Igor Levko <spama@huxpeha.het> wrote:
IL > just my 1 cent - switching between threads is much faster then between
IL > tasks.
IL > cheers,
IL > Igor
Based on what?
I would agree that your more likely to keep things in cache if it’s all
the same process.
Based on what?
Based on QNX 6.1 evaluation report by Dedicated Systems.
If my memory serves me right thread context switch latency was 4 times less
then
task switch latency.
I would agree that your more likely to keep things in cache if it’s all
the same process.
I believe that context switch should be part of kernel …
cheers,
Igor
Bill Caroselli <qtps@earthlink.net> wrote:
Igor Levko <> spama@huxpeha.het> > wrote:
IL > just my 1 cent - switching between threads is much faster then between
IL > tasks.IL > cheers,
IL > IgorBased on what?
I would agree that your more likely to keep things in cache if it’s all
the same process.
Based on the fact that a thread-to-thread switch in the same process
will not require any MMU or other such type of work to change the
address space, while a process to process switch will require such
work.
This should, in fact, be normal and expected.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:c2tdmu$4bp$1@nntp.qnx.com…
Bill Caroselli <> qtps@earthlink.net> > wrote:
Igor Levko <> spama@huxpeha.het> > wrote:
IL > just my 1 cent - switching between threads is much faster then
between
IL > tasks.IL > cheers,
IL > IgorBased on what?
I would agree that your more likely to keep things in cache if it’s all
the same process.Based on the fact that a thread-to-thread switch in the same process
will not require any MMU or other such type of work to change the
address space, while a process to process switch will require such
work.But a thread to thread switch that belong to different process is a the same
a process to process.
I wonder how many thread to thread switch occurs compare to process to
process switch in a typical system?
This should, in fact, be normal and expected.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
DG > Bill Caroselli <qtps@earthlink.net> wrote:
Igor Levko <> spama@huxpeha.het> > wrote:
IL > just my 1 cent - switching between threads is much faster then between
IL > tasks.IL > cheers,
IL > IgorBased on what?
I would agree that your more likely to keep things in cache if it’s all
the same process.
DG > Based on the fact that a thread-to-thread switch in the same process
DG > will not require any MMU or other such type of work to change the
DG > address space, while a process to process switch will require such
DG > work.
DG > This should, in fact, be normal and expected.
I was not aware of this. This is useful to know.
See, still thinking QNX4!
Mario Charest postmaster@127.0.0.1 wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
But a thread to thread switch that belong to different process is a the same
a process to process.I wonder how many thread to thread switch occurs compare to process to
process switch in a typical system?
I’m not sure I know what a “typical” system is, anymore. But, I have
seen a goodly number of large, multithreaded (100) processes. For
those people, thread-to-thread within a process is a common case.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.