linux多核与线程、进程运行

CPU管理的特点是自我管理，除了再启动、休眠、调频受控于CPU0的工作以外，处理器相关的绝大部分工作都是由处理器自我管理的。处理器是内核的执行体，又被内核控制，内核就是一个的指令集。内核中已经存在了表征处理器运行状态的结构体，处理器在运行是将自己的状态记录在这些结构体中，而处理器也能通过别的处理器的表征结构体了解其他处理器状态或对其发起控制。

多线程与并行计算的区别

(1)多线程的作用不只是用作并行计算，他还有很多很有益的作用。

还在单核时代，多线程就有很广泛的应用，这时候多线程大多用于降低阻塞（意思是类似于

while(1)

{

if(flag==1)

break;

sleep(1);

}

这样的代码）带来的CPU资源闲置,注意这里没有浪费CPU资源，去掉sleep(1)就是纯浪费了。

阻塞在什么时候发生呢？一般是等待IO操作（磁盘，数据库，网络等等）。此时如果单线程，CPU会干转不干实事（与本程序无关的事情都算不干实事，因为执行其他程序对我来说没意义），效率低下（针对这个程序而言），例如一个IO操作要耗时10毫秒，CPU就会被阻塞接近10毫秒，这是何等的浪费啊！要知道CPU是数着纳秒过日子的。

所以这种耗时的IO操作就用一个线程Thread去代为执行，创建这个线程的函数（代码）部分不会被IO操作阻塞，继续干这个程序中其他的事情，而不是干等待（或者去执行其他程序）。

同样在这个单核时代，多线程的这个消除阻塞的作用还可以叫做“并发”，这和并行是有着本质的不同的。并发是“伪并行”，看似并行，而实际上还是一个CPU在执行一切事物，只是切换的太快，我们没法察觉罢了。例如基于UI的程序（俗话说就是图形界面），如果你点一个按钮触发的事件需要执行10秒钟，那么这个程序就会假死，因为程序在忙着执行，没空搭理用户的其他操作；而如果你把这个按钮触发的函数赋给一个线程，然后启动线程去执行，那么程序就不会假死，继续相应用户的其他操作。但是，随之而来的就是线程的互斥和同步、死锁等问题，详细见有关文献。

现在是多核时代了，这种线程的互斥和同步问题是更加严峻的，单核时代大都算并发，多核时代真的就大为不同，为什么呢？具体细节请参考有关文献。我这里简单解释一下，以前volatile型变量的使用可以解决大部分问题，例如多个线程共同访问一个Flag标志位，如果是单核并发，基本不会出问题（P.S.在什么情况下会出问题呢？Flag有多个，或者是一个数组，这时候只能通过逻辑手段搞定这个问题了，多来几次空转无所谓，别出致命问题就行），因为CPU只有一个，同时访问这个标志位的只能有一个线程，而多核情况下就不太一样了，所以仅仅volatile不太能解决问题，这就要用到具体语言，具体环境中的“信号量”了，Mutex，Monitor，Lock等等，这些类都操作了硬件上的“关中断”，达到“原语”效果，对临界区的访问不被打断的效果，具体就不解释了，读者可以看看《现代操作系统》。

线程越多越好吗？什么时候才有必要用多线程？

线程必然不是越多越好，线程切换也是要开销的，当你增加一个线程的时候，增加的额外开销要小于该线程能够消除的阻塞时间，这才叫物有所值。

Linux自从2.6内核开始，就会把不同的线程交给不同的核心去处理。Windows也从NT.4.0开始支持这一特性。

什么时候该使用多线程呢？这要分四种情况讨论：

a.多核CPU——计算密集型任务。此时要尽量使用多线程，可以提高任务执行效率，例如加密解密，数据压缩解压缩（视频、音频、普通数据），否则只能使一个核心满载，而其他核心闲置。

b.单核CPU——计算密集型任务。此时的任务已经把CPU资源100%消耗了，就没必要也不可能使用多线程来提高计算效率了；相反，如果要做人机交互，最好还是要用多线程，避免用户没法对计算机进行操作。

c.单核CPU——IO密集型任务，使用多线程还是为了人机交互方便，

d.多核CPU——IO密集型任务，这就更不用说了，跟单核时候原因一样。

4.程序员需要掌握的技巧/技术

(1)减少串行化的代码用以提高效率。这是废话。

(2)单一的共享数据分布化：把一个数据复制很多份，让不同线程可以同时访问。

(3)负载均衡，分为静态的和动态的两种。

实际上，如果你没有对你的进程做过特殊处理的话，LINUX内核是有可能把它放到多个CPU处理器上运行的，这是内核的负载均衡。上文说过，每个处理器上有一个runqueue队列，表示这颗处理器上处于run状态的进程链表，在多处理器的内核中，就会有多个runqueue，而如果他们的大小很不均衡，就会触发内核的load_balance函数。这个函数会把某个CPU处理器上过多的进程移到runqueue元素相对少的CPU处理器上。

举个例子来简单说明这个过程吧。当我们刚fork出一个子进程时，子进程也还在当前CPU处理器的runqueue里，它与父进程均分父进程的时间片。当然，时间片与多处理器间的负载均衡没有关系。假设我们的系统是双核的，父进程运行在cpu0上，那么这个fork出来的进程也是在cpu0的runqueue中。

那么，什么时候会发生负载均衡呢？

1、当cpu1上的runqueue里一个可运行进程都没有的时候。这点很好理解，cpu1无事可作了，这时在cpu1上会调用load_balance，发现在cpu0上还有许多进程等待运行，那么它会从cpu0上的可运行进程里找到优先级最高的进程，拿到自己的runqueue里开始执行。

2、第1种情形不适用于运行队列一直不为空的情况。例如，cpu0上一直有10个可运行进程，cpu1上一直有1个可运行进程，显然，cpu0上的进程们得到了不公平的对待，它们拿到cpu的时间要小得多，第1种情形下的load_balance也一直不会调用。所以，实际上，每经过一个时钟节拍，内核会调用scheduler_tick函数，而这个函数会做许多事，例如减少当前正在执行的进程的时间片，在函数结尾处则会调用rebalance_tick函数。rebalance_tick函数决定以什么样的频率执行负载均衡。

当我们希望我们的进程一直在某个CPU上运行时，内核提供了相应的系统调用，系统API sched_getaffinity会返回当前进程使用的CPU的掩码，而sched_getaffinity则可以设定该进程只能在哪几个CPU上运行。当我们强烈期待某个进程运行时，或者想自己来实现进程运行时的CPU间的负载均衡，可以考虑使用这个方法。