时间片轮转调度中唯一有趣的一点是时间片的长度。从一个进程切换到另一个进程是需要一定时间的--保存和装入寄存器值及内存映像，更新各种表格和队列等。假如进程切换(process switch) - 有时称为上下文切换(context switch)，需要5毫秒，再假设时间片设为20毫秒，则在做完20毫秒有用的工作之后，CPU将花费5毫秒来进行进程切换。CPU时间的20%被浪费在了管理开销上。
为了提高CPU效率，我们可以将时间片设为500毫秒。这时浪费的时间只有1%。但考虑在一个分时系统中，如果有十个交互用户几乎同时按下回车键，将发生什么情况？假设所有其他进程都用足它们的时间片的话，最后一个不幸的进程不得不等待5秒钟才获得运行机会。多数用户无法忍受一条简短命令要5秒钟才能做出响应。同样的问题在一台支持多道程序的个人计算机上也会发生。
结论可以归结如下：时间片设得太短会导致过多的进程切换，降低了CPU效率；而设得太长又可能引起对短的交互请求的响应变差。将时间片设为100毫秒通常是一个比较合理的折衷。
*********************************************************
多任务 多线程解释
引言
早期的计算硬件十分复杂,但是操作系统执行的功能确十分的简单。那个时候的操作系统在任一时间点只能执行一个任务,也就是同一时间只能执行一个程序。多个任务的执行必须得轮流执行,在系统里面进行排队等候。由于计算机的发展,要求系统功能越来越强大，这个时候出现了分时操作的概念：每个运行的程序占有一定的处理机时间,当这个占有时间结束后,在等待队列等待处理器资源的下一个程序就开始投入运行。注意这里的程序在占有一定的处理器时间后并没有运行完毕，可能需要再一次或多次分配处理器时间。那么从这里可以看出，这样的执行方式显然是多个程序的并行执行，但是在宏观上，我们感觉到多个任务是同时执行的，因此多任务的概念就诞生了。每个运行的程序都有自己的内存空间,自己的堆栈和环境变量设置。每一个程序对应一个进程，代表着执行一个大的任务。一个进程可以启动另外一个进程,这个被启动的进程称为子进程。父进程和子进程的执行只有逻辑上的先后关系，并没有其他的关系，也就是说他们的执行是独立的。但是，可能一个大的程序（代表着一个大的任务）,可以分割成很多的小任务，为了功能上的需要也有可能是为了加快运行的速度，可能需要同一时间执行多个任务(每个任务分配一个多线程来执行相应的任务)。举个例子来说,你正在通过你的web浏览器查看一些精彩的文章，你需要把好的文章给下载下来，可能有些非常精彩的文章你需要收藏起来，你就用你的打印机打印这些在线的文章。在这里，浏览器一边下载HTML格式的文章，一边还要打印文章。这就是一个程序同时执行多个任务，每个任务分配一个线程来完成。因此我们可以看出一个程序同时执行多个任务的能力是通过多线程来实现的。
多线程VS多任务
正如上面所说的,多任务是相对与操作系统而言,指的是同一时间执行多个程序的能力,虽然这么说,但是实际上在只有一个CPU的条件下不可能同时执行两个以上的程序。CPU在程序之间做高速的切换,使得所有的程序在很短的时间之内可以得到更小的CPU时间,这样从用户的角度来看就好象是同时在执行多个程序。多线程相对于操作系统而言,指的是可以同时执行同一个程序的不同部分的能力,每个执行的部分被成为线程。所以在编写应用程序时,我们必须得很好的设计以 避免不同的线程执行时的相互干扰。这样有助于我们设计健壮的程序,使得我们可以在随时需要的时候添加线程。
线程的概念
线程可以被描述为一个微进程,它拥有起点,执行的顺序系列和一个终点。它负责维护自己的堆栈,这些堆栈用于异常处理,优先级调度和其他一些系统重新恢复线程执行时需要的信息。从这个概念看来，好像线程与进程没有任何的区别，实际上线程与进程是肯定有区别的：
一个完整的进程拥有自己独立的内存空间和数据,但是同一个进程内的线程是共享内存空间和数据的。一个进程对应着一段程序,它是由一些在同一个程序里面独立的同时的运行的线程组成的。线程有时也被称为并行运行在程序里的轻量级进程,线程被称为是轻量级进程是因为它的运行依赖与进程提供的上下文环境,并且使用的是进程的资源。
在一个进程里,线程的调度有抢占式或者非抢占的模式。
在抢占模式下，操作系统负责分配ＣＰＵ时间给各个进程，一旦当前的进程使用完分配给自己的ＣＰＵ时间，操作系统将决定下一个占用ＣＰＵ时间的是哪一个线程。因此操作系统将定期的中断当前正在执行的线程，将ＣＰＵ分配给在等待队列的下一个线程。所以任何一个线程都不能独占ＣＰＵ。每个线程占用ＣＰＵ的时间取决于进程和操作系统。进程分配给每个线程的时间很短,以至于我们感觉所有的线程是同时执行的。实际上,系统运行每个进程的时间有2毫秒,然后调度其他的线程。它同时他维持着所有的线程和循环,分配很少量的ＣＰＵ时间给线程。 线程的的切换和调度是如此之快,以至于感觉是所有的线程是同步执行的。
调度是什么意思?调度意味着处理器存储着将要执行完ＣＰＵ时间的进程的状态和将来某个时间装载这个进程的状态而恢复其运行。然而这种方式也有不足之处,一个线程可以在任何给定的时间中断另外一个线程的执行。假设一个线程正在向一个文件做写操作,而另外一个线程中断其运行,也向同一个文件做写操作。 Windows 95/NT, UNIX使用的就是这种线程调度方式。
在非抢占的调度模式下,每个线程可以需要ＣＰＵ多少时间就占用ＣＰＵ多少时间。在这种调度方式下,可能一个执行时间很长的线程使得其他所有需要ＣＰＵ的线程”饿死”。在处理机空闲，即该进程没有使用ＣＰＵ时，系统可以允许其他的进程暂时使用ＣＰＵ。占用ＣＰＵ的线程拥有对ＣＰＵ的控制权，只有它自己主动释放ＣＰＵ时，其他的线程才可以使用ＣＰＵ。一些I/O和Windows 3。x就是使用这种调度策略。
在有些操作系统里面，这两种调度策略都会用到。非抢占的调度策略在线程运行优先级一般时用到，而对于高优先级的线程调度则多采用抢占式的调度策略。如果你不确定系统采用的是那种调度策略，假设抢占的调度策略不可用是比较安全的。在设计应用程序的时候，我们认为那些占用ＣＰＵ时间比较多的线程在一定的间隔是会释放ＣＰＵ的控制权的，这时候系统会查看那些在等待队列里面的与当前运行的线程同一优先级或者更高的优先级的线程，而让这些线程得以使用ＣＰＵ。如果系统找到一个这样的线程，就立即暂停当前执行的线程和激活满足条件的线程。如果没有找到同一优先级或更高级的线程，当前线程还继续占有ＣＰＵ。当正在执行的线程想释放ＣＰＵ的控制权给一个低优先级的线程，当前线程就转入睡眠状态而让低优先级的线程占有ＣＰＵ。
在多处理器系统，操作系统会将这些独立的线程分配给不同的处理器执行，这样将会大大的加快程序的运行。线程执行的效率也会得到很大的提高，因为将线程的分时共享单处理器变成了分布式的多处理器执行。这种多处理器在三维建模和图形处理是非常有用的。
需要多线程吗
我们发出了一个打印的命令，要求打印机进行打印任务，假设这时候计算机停止了响应而打印机还在工作，那岂不是我们的停止手上的事情就等着这慢速的打印机打印？所幸的是，这种情况不会发生，我们在打印机工作的时候还可以同时听音乐或者画图。因为我们使用了独立的多线程来执行这些任务。你可能会对多个用户同时访问数据库或者web服务器感到吃惊，他们是怎么工作的？这是因为为每个连接到数据库或者web服务器的用户建立了独立的线程来维护用户的状态。如果一个程序的运行有一定的顺序，这时候采用这种方式可能会出现问题，甚至导致整个程序崩溃。如果程序可以分成独立的不同的任务，使用多线程，即使某一部分任务失败了，对其他的也没有影响，不会导致整个程序崩溃。
毫无疑问的是，编写多线程程序使得你有了一个利器可以驾奴非多线程的程序，但是多线程也可能成为一个负担或者需要不小的代价。如果使用的不当，会带来更多的坏处。如果一个程序有很多的线程，那么其他程序的线程必然只能占用更少的ＣＰＵ时间；而且大量的ＣＰＵ时间是用于线程调度的；操作系统也需要足够的内存空间来维护每个线程的上下文信息；因此，大量的线程会降低系统的运行效率。因此，如果使用多线程的话，程序的多线程必须设计的很好，否则带来的好处将远小于坏处。因此使用多线程我们必须小心的处理这些线程的创建，调度和释放工作。
多线程程序设计提示
有多种方法可以设计多线程的应用程序。正如后面的文章所示，我将给出详细的编程示例，通过这些例子，你将可以更好的理解多线程。线程可以有不同的优先级，举例子来说，在我们的应用程序里面，绘制图形或者做大量运算的同时要接受用户的输入，显然用户的输入需要得到第一时间的响应，而图形绘制或者运算则需要大量的时间，暂停一下问题不大，因此用户输入线程将需要高的悠闲级，而图形绘制或者运算低优先级即可。这些线程之间相互独立，相互不影响。
在上面的例子中，图形绘制或者大量的运算显然是需要站用很多的ＣＰＵ时间的，在这段时间，用户没有必要等着他们执行完毕再输入信息，因此我们将程序设计成独立的两个线程，一个负责用户的输入，一个负责处理那些耗时很长的任务。这将使得程序更加灵活，能够快速响应。同时也可以使得用户在运行的任何时候取消任务的可能。在这个绘制图形的例子中，程序应该始终负责接收系统发来的消息。如果由于程序忙于一个任务，有可能会导致屏幕变成空白，这显然需要我们的程序来处理这样的事件。所以我必须得有一个线程负责来处理这些消息，正如刚才所说的应该触发重画屏幕的工作。
我们应该把握一个原则，对于那些对时间要求比较紧迫需要立即得到相应的任务，我们因该给予高的优先级，而其他的线程优先级应该低于她的优先级。侦听客户端请求的线程应该始终是高的优先级，对于一个与用户交互的用户界面的任务来说，它需要得到第一时间的响应，其优先级因该高优先级。
多进程和多线程的优缺点
写服务程序为提高性能得到的：
最开始我们的程序的一个数据处理模块为单机版的，后来开发服务器版，需要支持多个数据采集终端，这样就有一个性能考虑了。开始我采用多线程方式，结果发现速度没有提高，原来那个单机版的数据处理库（DLL）由于使用了大量的字符串操作，导致效率极其低下！原来单机的时候，一个线程可以处理300KB/s的数据，结果在在服务器上面，开两个线程运行结果每个线程只能处理20~30KB/s左右！与预期的效果相差很远。我以为是内存操作太多的原因，于是采用内存池，改用内存次后，速度可以提高到30~40KB，不理想。后来测试发现，如果单个CPU的话，即使开两个线程，总共也能达到300KB/s左右的速度，原来在真正的多CPU下运行的时候，由于内存分配操作，加锁的利害，导致效率急剧下降，Borlndmm.dll对多CPU下多线程支持很不好，后来我们采用QMM，经过测试，可以提高到1.5倍左右速度（50~60KB/s），但是还是满足不了要求！这样要么提高DLL中的效率，要么改用其它的方式。由于DLL开发较久，而且牵扯太大，改动不现实，最后采取了多进程的方式。最开始我写了个DCOM，结果测试效率也非常低下（2CPU，2线程，70~80KB/s），经过查找，发现在COM接口调用上面开销太大，达不到理想的效果。最后采用消息方式和内存映射共享来做，效果比较理想：开发一个数据处理代理程序Agent，代理程序有一个简单的消息处理窗口，程序和服务共享某些内存块，服务在接受到数据后，写入共享内存块，并发送消息通知Agent，Agent在收到消息，后立即Copy数据到自身的内存缓冲列表中，并立即返回；Agent有一个线程在不停地Check这个缓存列表，如果有数据，则取出数据并进行处理，处理完毕后，把结果写入共享内存块，然后通知服务获取数据。效果非常理想：两个CPU，每个CPU都可以处理250KB/s左右。当然这个结构还是有问题的，如果数据一直不断地来，超过系统处理能力，则Agent会消耗越来越多的内存，并最终可能Crash掉，丢失部分数据，但是这个处理能力可以靠加CPU解决，对我们的应用来说，已经足够了~。当然如果用阻塞方式，不会丢失数据，但是效率只能达到每线程120~140KB/s的速度，这个对我们应用也够了，到时候4个CPU就能达到一定的要求。
在实现缓存列表的时候，越来采用TList作，效果太低，最后用链表实现一个FIFO队列，效果很好~。
Windows的消息队列是有最大的限制的：10000；最开始没有注意到这个，来了数据后，送入缓冲区，并PostMessage给Agent的窗体，最后发现丢了很多数据，越来消息太多，后面的消息冲掉了老的消息，导致数据丢失，没有办法，自己管理缓冲列表，并采用线程解决掉了。
教训：
DLL尽可能要提高效率；
内存分配释放操作不要太多，这个是很没有效率的动作；
多进程在多CPU下的代码和结构要仔细考虑；
系统的瓶颈有很多，你改掉一个就有有另外一个，要找出影响最大的那个瓶颈；
别吝啬内存，能够使用内存池就用内存池，能够用线程池就用线程池；
使用消息队列，一定要注意消息的大小限制；
每个进程只能有2GB地址空间，多个进程的话，就可以大大扩展地址空间，只要多插内存条既可；
多线程的优点：
- 无需跨进程边界；
- 程序逻辑和控制方式简单；
- 所有线程可以直接共享内存和变量等；
- 线程方式消耗的总资源比进程方式好；
多线程缺点：
- 每个线程与主程序共用地址空间，受限于2GB地址空间；
- 线程之间的同步和加锁控制比较麻烦；
- 一个线程的崩溃可能影响到整个程序的稳定性；
- 到达一定的线程数程度后，即使再增加CPU也无法提高性能，例如Windows Server 2003，大约是1500个左右的线程数就快到极限了（线程堆栈设定为1M），如果设定线程堆栈为2M，还达不到1500个线程总数；
- 线程能够提高的总性能有限，而且线程多了之后，线程本身的调度也是一个麻烦事儿，需要消耗较多的CPU
多进程优点：
- 每个进程互相独立，不影响主程序的稳定性，子进程崩溃没关系；
- 通过增加CPU，就可以容易扩充性能；
- 可以尽量减少线程加锁/解锁的影响，极大提高性能，就算是线程运行的模块算法效率低也没关系；
- 每个子进程都有2GB地址空间和相关资源，总体能够达到的性能上限非常大
多线程缺点：
- 逻辑控制复杂，需要和主程序交互；
- 需要跨进程边界，如果有大数据量传送，就不太好，适合小数据量传送、密集运算
- 多进程调度开销比较大；
最好是多进程和多线程结合，即根据实际的需要，每个CPU开启一个子进程，这个子进程开启多线程可以为若干同类型的数据进行处理。当然你也可以利用多线程+多CPU+轮询方式来解决问题……
方法和手段是多样的，关键是自己看起来实现方便有能够满足要求，代价也合适。