选择线程与过程时如何或要考虑的要点/领域 [英] How or what are the points/area to consider while choosing a threads verses process

问题描述

你好，

我必须决定哪种方法最适合嵌入式系统的性能和速度.
我需要知道在哪些方面可以比较性能/速度等，从而为具有以下条件的系统提供最合适的设计:
a)基于过程的经文
b)基于线程.


问候，
AK

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

推荐答案

您好，Eugen！
在此 [

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.

您通常不会根据性能在进程和线程之间进行选择.从操作系统的角度来看，每一个都将导致上下文切换的开销.

如果希望所有正在运行的活动都在同一地址空间中包含数据，则可以选择多线程方法.另一方面，如果您的活动相对彼此分离，并且只需要在此处和那里进行某种同步，则基于过程的方法将行得通，并且通常更易于实现.而且某些嵌入式环境甚至无法为您提供选择，因为它们每个进程都不提供多个线程.

从讨论线程中提取的其他信息:

因此，您有多个应并行运行的活动.当它们作为线程驻留在同一进程中时，它们共享一个大的内存空间，这有时是好消息(线程之间的通信更加容易)，也可能是坏消息，因为一个线程可以写入另一个内存，因此更容易受到攻击.相反，当它们在单独的进程中运行时，它们彼此之间更加独立.例如，您可以关闭一个进程，也可以通过简单的方法(如操作系统命令)将其重新启动.但是这些过程之间的通信更加困难.您必须使用共享内存部分或某种类型的进程间通信，例如套接字或远程过程调用.多个进程会占用更多的系统资源，因为虚拟内存页表和其他按进程分配的数据结构会占用内存.相比之下，线程的重量更轻，这就是首先发明线程的原因.
遵循这些思路的想法就是我所说的建筑设计，您应该在研究性能问题时更多地关注它们.从线程到线程的上下文更改通常比进程到进程的上下文更改快一点.但是这些差异在大多数情况下与您决定以哪种方式实施系统无关.

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.

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.

//重点/领域是什么?

可能的开始:):
-处理数据的种类(共享/分开)
-沟通的必要性(工人之间)
-可能出现异常的安全性(线程可能会使其整个进程崩溃)

// 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)

这篇关于选择线程与过程时如何或要考虑的要点/领域的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！