进程线程总是无法理解，小记一下

    进程和线程都是一个时间段的描述，是CPU工作时间段的描述，不过是颗粒大小不同。

    CPU+RAM+各种资源（比如显卡，光驱，键盘，GPS，等等外设）构成我们的电脑，但是电脑的运行，实际就是CPU和相关寄存器以及RAM之间的事情。（计算机导论应该讲     过）

  

     CPU的速度相当非常快，寄存器仅仅能追上他的脚步，RAM和别的挂在个总线上的设备完全是望其项背。那当多个任务要执行的时候怎么办呢？轮着来？或者优先级高谁来？

不管怎么样的策略，一句话就是在CPU看来就是轮着来的。

     执行一段程序代码，实现一个功能的过程：

     当得到CPU的时候，相关的资源必须就位，就是显卡啊，GPS啊什么的必须就位，然后CPU开始执行。这里除了CPU以外所有的就构成了程序的执行环境，也就是我们所定义的程序上下文。当这个程序执行完了，或者分配给他的CPU执行时间用完了，那么它就要被切换出去，等待下一次CPU的临幸。在被切换出去的最后一步工作就是保存程序上下文本，因为这个是下次他被临幸的运行环境，必须保存。

      在CPU看来所有的任务都是一个一个的轮流执行的，具体的轮流方法就是：

       先加载程序A的上下文，然后开始执行A，保存A的上下文，调入下一个要执行的程序B的程序上下文，然后开始执行B，保存程序B的上下文。

      

      进程和线程就是在这样的背景下出来的，两个名词不过是对应的CPU时间段的描述。

      进程就是包括上下文切换的程序执行时间总和 = CPU加载上下文+CPU执行+CPU保存上下文

      

      线程是什么？

      进程的颗粒度太大，每次都要有上下的调入，保存，调出。如果我们把进程比喻为一个正在运行在电脑上的软件，那么一个软件的执行不可能是一条逻辑执行的，必须有多个分支和多个程序段，就好比要实现程序A，实际分出去a,b,c等多个块组合而成 。那么这具体执行就可能变成：

      程序A得到CPU=》CPU加载上下文，开始执行程序A的a小段，然后执行A的b小段，然后执行A的c小段，最后CPU保存A的上下文。

      这里a，b，c的执行共享A的上下文，CPU在执行的时候没有进行上下文切换的。这里的a，b，c就是线程，也就是说线程是共享了进程上下文环境的更细小的CPU时间段。

      资源共享是线程，资源独立是进程；开销小线程，开销大进程。

      

      在DOS时代，操作系统处理问题都是单任务的，我想做听音乐和看小说两件事儿，那么一定要先排一下顺序。随着计算机的发展便出现了并发，是听音乐和看电影这两件事可以同时进行。

     CPU多核心的计算机（拥有多个处理器或者多核处理器或者两者兼具），这些计算机都能并行运行超过一个任务。一个双核计算机在处理这两个任务时，每个任务可以在各自的核心执行。这样可以实现一边听歌和看小说。但是，通常我们会打开电脑同时做很多事情，浏览不同的网页，打开文本编辑器，听歌，发qq等。硬件并发会受到硬件核心数或者处理器的限制。于是存在另一种实现并发的方式。

       多线程：

       我们的CPU也越来越快，CPU可以同时干多个活都没问题。我们可以一边看小说和一边听歌。很多语言支持多线程。

       python 提供了thread和threading模块实现多线程。

       C++也有头文件<thread>作为对多线程的支持。

      多进程编程相对安全，因为一个进程崩溃，主进程不会影响。多线程在开销上比较小，但是一个崩溃就全崩溃了。一般是进程与线程共用。多进程开启任务，线程负责处理和监控。