How or what are the points/area to consider while choosing a threads verses process

Question

1.00/5 (1 vote)

See more:

Hello,

I have to make a decision on what is the best suitable approach for performance and speed of an embedded system.
I need to know what are the areas to compare the performance/speed etc. to come out with a best suitable design for a system with:
a) process based verses
b) thread based.

Regards,
AK

Posted 13-Aug-12 19:29pm

Ashoka K

Add a Solution

Comments

Kenneth Haugland 14-Aug-12 1:42am

That would depende on how the overoll picture is I would guess... Thread based seems a lot easyer though..

Peter_in_2780 14-Aug-12 1:56am

May not exactly match your situation, but the (older versions of) Apache web server had two "multiprocessing" models, one thread-based and one process-based. There has been a lot of discussion over the years about choosing between them and when one is better than the other. Start by searching apache.org for terms like "worker" and "prefork".

Sergey Alexandrovich Kryukov 14-Aug-12 2:30am

The question is totally invalid, because there is no a cookbook recipes for that. In most situations, threads should be preferred, but we have no idea what is your situation...
--SA

nv3 14-Aug-12 5:12am

I don't see the question as being invalid at all. It just entails so many aspects that it is hard to answer in a few sentences. There is nothing that can be done with one and can't be done with the other. And that in fact rises the question which technique to use in this case. And like in so many other situations the striving for performance is put way to much into the foreground of all considerations. The architectural questions are what should dominate the multiple processes / multiple threads decision.

Sergey Alexandrovich Kryukov 14-Aug-12 11:35am

I don't say it makes no sense at all, but formally it is invalid, because -- "it depends". Even if you created a whole article (or a book?) on this interesting topic (which I can imagine; and it might make some sense), you would not formally answer this question. It will be just a set of thought and probably recommendations "on related topics".
--SA

Ashoka K 15-Aug-12 3:18am

Thanks for the answer. can you please point me or explain little bit more on what you mean by "The architectural questions are what should dominate the multiple processes / multiple threads decision".

nv3 15-Aug-12 3:37am

So you have multiple activities that should run in parallel. When they reside as threads in the same process they share one big memory space, which is sometimes good (easier communication between the threads) or bad, more vulnerable as one thread can write into another's memory. When they instead run in separate processes, they are more independent of each other. You can for instance take one process down or restart it by simple means as operating system commands. But the communication between those processes is more difficult. You have to use shared memory sections or some sort inter-process communication like sockets or remote procedure calls. Multiple processes take up more system resources, because virtual memory page tables and other process-wise data structure take up memory. Threads are more light-weight in comparison, which was the reason threads have been invented in the first place.

Thoughts along these lines are what I meant by architectural design and you should pay more attention to them then looking into the performance issues. Context changes from thread-to-thread are usually slightly faster than process-to-process context changes. But these differences are in most cases not relevant for your decision in which way to implement your system.

Volynsky Alex 14-Aug-12 6:38am

The impact of non-schedulability on embedded system performance is deeply researched in this article:
http://www.jiafuwan.net/Conference/Impact.pdf

Ashoka K 15-Aug-12 3:10am

Thanks to all.
I know it it is difficult to answer this question. But i just wanted to know which all the areas we must consider before going for any specific design in general.

3 solutions

Solution 3

Hi Eugen!
In this[^] article, an autor is shows a specific transaction level modeling approach for performance evaluation of hardware/software architectures. This approach relies on a generic execution model that exhibits light modeling effort. Created models are used to evaluate by simulation expected processing and memory resources according to various architectures. The proposed execution model relies on a specific computation method defined to improve the simulation speed of transaction level models.

Maybe it can help for you.

Posted 14-Aug-12 0:35am

Volynsky Alex

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

nv3 · Accepted Answer · 2012-08-13T20:27:00

You don't typically choose between processes and threads by performance. Each one will incur the overhead of a context switch from the the perspective of the operating system.

You choose a multi-threaded approach if there is data that you want to have around in the same address space for all your running activities. If on the other hand your activities are relatively detached from each other and just need some sort of synchronization here and there, a process-based approach will do and is generally easier to implement. And some embedded environments don't even give you a choice as they don't offer multiple threads per process.

[EDIT] Additional information extracted from the discussion thread:

So you have multiple activities that should run in parallel. When they reside as threads in the same process they share one big memory space, which is sometimes good (easier communication between the threads) or bad, more vulnerable as one thread can write into another's memory. When they instead run in separate processes, they are more independent of each other. You can for instance take one process down or restart it by simple means as operating system commands. But the communication between those processes is more difficult. You have to use shared memory sections or some sort inter-process communication like sockets or remote procedure calls. Multiple processes take up more system resources, because virtual memory page tables and other process-wise data structure take up memory. Threads are more light-weight in comparison, which was the reason threads have been invented in the first place.

Thoughts along these lines are what I meant by architectural design and you should pay more attention to them then looking into the performance issues. Context changes from thread-to-thread are usually slightly faster than process-to-process context changes. But these differences are in most cases not relevant for your decision in which way to implement your system.

Eugen Podsypalnikov · Accepted Answer · 2012-08-13T20:49:00

Solution 2

// what are the points/area ?

A possible begin :) :
- Kind of processing data (shared/apart)
- Communication necessity (between the workers)
- Safety on possible exceptions (a thread can crash its whole process)

Posted 13-Aug-12 20:49pm

Eugen Podsypalnikov