Python 中没有真正的并行，只有并发
无论你的机器有多少个CPU, 同一时间只有一个Python解析器执行。这也和大部分解释型语言一致， 都不支持并行。这应该是python设计的先天缺陷。
python通过多进程实现多并行，充分利用多处理器，弥补了语言层面不支持多并行的缺点。Python, Node.js等解释型语言似乎都是通过这种方式来解决同一个时间，一个解释器只能处理一段程序的问题， 十分巧妙。
抛开各种技术细节，从应用程序角度讲：
1、在单核计算机里，有一个资源是无法被多个程序并行使用的：cpu。
没有操作系统的情况下，一个程序一直独占着全都cpu。
如果要有两个任务来共享同一个CPU，程序员就需要仔细地为程序安排好运行计划--某时刻cpu和由程序A来独享，下一时刻cpu由程序B来独享
而这种安排计划后来成为OS的核心组件，被单独名命为“scheduler”，即“调度器”，它关心的只是怎样把单个cpu的运行拆分成一段一段的“运行片”，轮流分给不同的程序去使用，而在宏观上，因为分配切换的速度极快，就制造出多程序并行在一个cpu上的假象。
2、在单核计算机里，有一个资源可以被多个程序共用，然而会引出麻烦：内存。
在一个只有调度器，没有内存管理组件的操作系统上，程序员需要手工为每个程序安排运行的空间 -- 程序A使用物理地址0x00-0xff,程序B使用物理地址0x100-0x1ff，等等。
然而这样做有个很大的问题：每个程序都要协调商量好怎样使用同一个内存上的不同空间，软件系统和硬件系统千差万别，使这种定制的方案没有可行性。
为了解决这个麻烦，计算机系统引入了“虚拟地址”的概念，从三方面入手来做：
2.1、硬件上，CPU增加了一个专门的模块叫MMU，负责转换虚拟地址和物理地址。
2.2、操作系统上，操作系统增加了另一个核心组件：memory management，即内存管理模块，它管理物理内存、虚拟内存相关的一系列事务。
2.3、应用程序上，发明了一个叫做【进程】的模型，（注意）每个进程都用【完全一样的】虚拟地址空间，然而经由操作系统和硬件MMU协作，映射到不同的物理地址空间上。不同的【进程】，都有各自独立的物理内存空间，不用一些特殊手段，是无法访问别的进程的物理内存的。
3、现在，不同的应用程序，可以不关心底层的物理内存分配，也不关心CPU的协调共享了。然而还有一个问题存在：有一些程序，想要共享CPU，【并且还要共享同样的物理内存】，这时候，一个叫【线程】的模型就出现了，它们被包裹在进程里面，在调度器的管理下共享CPu，拥有同样的虚拟地址空间，同时也共享同一个物理地址空间，然而，它们无法越过包裹自己的进程，去访问别一个进程的物理地址空间。
4、进程之间怎样共享同一个物理地址空间呢？不同的系统方法各异，符合posix规范的操作系统都提供了一个接口，叫mmap，可以把一个物理地址空间映射到不同的进程中，由不同的进程来共享。
5、PS：在有的操作系统里，进程不是调度单位（即不能被调度器使用），线程是最基本的调度单位，调度器只调度线程，不调度进程，比如VxWorks
2
1. 进程/CPU/线程三者，其实进程作为程序的一次执行（有独立的内存空间）这一特点，线程作为CPU调度单位这一特点。
2. 线程间同步是为了防止竞争（就是说因同时修改，而导致的数据不一致）。本质上讲，进程的内存空间是天然独立的，线程的内存空间是天然共享的。正因为如此，进程通信/线程同步才是系统编程的很大一块内容。
进程和线程简单而基本靠谱的定义如下：
1. 进程：程序的一次执行
2. 线程：CPU的基本调度单位
