进入thread线程的总结。
Thread Usage
我们已经有了process，为什么还需要thread线程呢？原因有以下四个：
- 在一个process里本就进行着各种活动（或者说任务），将一个process decompose成不同的threads使程序设计更为简单了，并且，同一个process的threads之间可以共享address space，这使threads 可以完成processes完成不了（或者完成困难）的任务。
- thread is lighter than process。 所以thread的创建等过程比process更简单。
- 实现了thread之后某方面的performance比没实现更强(overlap)。
- 在多CPU系统中实现真正的并行。
Thread Definition
A sequential execution stream within a process is called a thread(also called lightweight process).
同一个prcess的threads之间共享address space and OS resources，所以它们之间可以直接通信。 Each thread has its own stack,CPU registers,etc.
The Classcial Thread Model
从另一角度看待process，process其实是一组related resources的集合，process的工作就是分配resources让具体的threads去执行任务。
No Protection Between Threads
为什么threads之间不需要保护呢？对于processes来说，不同的process可能是由不同的user创建的，它们可能会产生竞争关系，这时候需要对它们的相关资源进行保护， 而对于threads来说，它们由同一user创建，是要相互配合去完成某一项任务，它们的目的是合作，所以不需要保护。
Public resources and private resources
threads之间也不是所有的resources都共享的，事实上也不可能全部共享，因为它们也需要完成不同的任务，这就意味着它们需要记录各自的state,stack and registers etc. 让我们来看一下threads之间什么是共享的什么是单一thread独有的。
Why each thread needs its own stack
为什么每个thread需要各自专属的stack呢？每个线程都需要保存各自被调用的过程，比如，X调用Y，Y又 调用Z，那么当Z执行时，X/Y/Z的信息会保存在各自的堆栈中。
Disadvantages
实现threads也不是一点缺点没有，它的缺点有两个：
- 它使得模型变得更加复杂了。
- 因为thread共享一些resources的关系可能出现问题。
POSIX Threads
To make it possible to write portable threaded programs, IEEE has defined a standard for threads in IEEE standard 1003.1c. The threads package it defines is called Pthreads. Most UNIX systems support it. The standard defines over 60 function calls, which is far too many to go over here. Instead, we will just describe a few of the major ones to give an idea of how it works.
Implementating Threads
实现thread有两种主要的方式：user space and the kernel. A hybrid implementation is also possible.
上图向我们展示了如何分别在user space和kernel中实现threads。
Implementating Threads in User Space
在User Space中实现threads一个很重要的特点就是，kernel对与threads一无所知。像process一样，threads也要实现类似于process table一样的东西，在threads中，要实现thread table， 在user space中，thread table由run-time system管理，
在User Space中实现threads有以下的优点：
- A user-level threads package can be implemented on an operating system that does not support threads.
- The procedure that saves the thread’s state and the scheduler are just local procedures, so invoking them is much more efficient than making a kernel call.
- They allow each process to have its own customized scheduling algorithm.
但是也有问题亟需解决：
-
How blocking system calls are implemented?
如果让thread直接使用system call的话会导致此process的所有threads都停止活动了（处于blocked状态），这违反了我们当初设计threads时的初衷，为什么所有threads 都会受到影响呢？因为kernel是不知道有threads的存在的，当某一个thread调用block system call，在kernel看来，此process调用了block system call，所以整个process的所有threads都blocked住了。 如何解决呢？第一个方法是把system callls变成nonblocking的状态，非常不现实。 第二个方法是封装可能会导致block的命令，比如封装read，在read调用之前先check一下是否安全，如果不会block，就read，如果 会导致block，那么就不调用read。 -
Another problem with user-level thread packages is that if a thread starts running, no other thread in that process will ever run unless the first thread voluntarily gives up the CPU.
因为kernel不知道thread的存在，所以无法进行资源的调度，只有当某一个进程自愿放弃CPU资源时其它thread才能运行。解决这个问题的方法第一个是设置一个clock interrupt，每到一定时间就让当前thread放弃CPU资源。 -
没看懂，下节课去问老师。
Implementating Threads in Kernel
两种实现方式的区别在于，kernel的thread table保存在kernel中并且由kernel来维护，而不是由runtime system维护。
kernel中实现的重要问题是: the cost of a system call is substantial，system call的代价太昂贵了。
但是kernel能够解决user-space的很多问题，比如不用担心system call的block会影响其它thread，也不用担心某一个thread一直占用CPU资源，这些都是kernel可以去管理的，但是也有问题，
有很多与thread相关的繁琐的问题需要解决。
Hybrid Implementations
Hybrid implementation是两者的结合，既有kernel thread也有user thread，kernel只知道kernel thread的存在并且每个kernel thread管理几个user threads。
Pop-Up Threads
两个进程进行通信的时候如何接受消息呢？要么是有一个thread专门处在block状态等待消息的到来，message到了这个thread开始处理消息，但也有另外一种方式解决这个问题，也就是Pop-up Thread。
当消息来的时候，创建THread去处理到来的消息，这个thread就是pop-up thread。 它的优点两个：
- Since they are brand new, they do not have any history—registers, stack, whatever—that must be restored.
- The result of using pop-up threads is that the latency between message arrival and the start of processing can be made very short.