关于对多线程在什么情况下利大于弊的分析。（前10个发言者肯定有分）

[temp]

我先发言：


为了提高CPU的利用率，为了保证程序的实时响应能力。我在这里使用了多线程技术，串口监视线程，数据分析线程，动态建立的数据处理线程可以‘同时’工作。注意，在单CPU的系统里，这样的‘同时’是一种错觉，实际上，还是多个线程轮流使用CPU。如前问所述，CPU的速度已经很快，系统效率的瓶颈不在CPU，而在串口和数据库服务器。所以，整个进程的效率会提高不少。

任何事物都有它的两面性，CPU在提高了系统‘通量’的同时。也带来了一些负面的影响，如果处理不好，会完全抵消使用多线程所带来的好处。

首先需要说明的是，使用多线程技术并不能节省CPU的操作，相反，系统还要在切换上下文中花一些时间。多线程只是提高了CPU的利用率而已。

加入额外的线程可以增加通量，但是加入过多的线程将会降低系统的性能，因为上下文交换将会成为一个重大的负担。上下文交换速度应该低的原因有两个：上下文交换占用了许多宝贵的时钟周期；更糟的是，上下文交换将处理器的缓存填满了没用的数据，替换这些数据可能是代价高昂的。

虽然Windows NT系统和Windows2000系统的稳定性可以承受系统内同时运行上千个线程，（我曾见过NT系统中运行1700个线程的时候）但是当线程开得过多的时候，将会出现整体运行效率大大降低的情况。因为，目前大多数的计算机都是单处理器(CPU)的，在这种机器上运行多线程程序，有时反而会降低系统的性能。如果两个非常活跃的线程为了抢夺对CPU的控制权，则在线程切换时会消耗很多的CPU资源，但对于大部分时间被阻塞的线程（例如等待文件I/O操作），则可用一个单独的线程来完成。这样，就可将CPU时间让出来，使程序获得更好的性能。因此，在设计多线程应用程序时，应慎重选择，并且视具体情况加以处理，使应用程序获得最佳的性能。

还可能有另一个问题也需要说明，动态的建立线程也需要花时间，但我确信这个时间比查一次数据库所花的时间要小的多。综合来看,在数据流量较大的情况下，还是利大于弊。所以我个人更倾向于使用多线程。

[temp]

这是我的论文的一部分，呵呵，欢迎指正。

[temp]

还有发言的吗？

[temp]

随便说些什么吧。

[multiplex]

在实时监控中,一边要从串口获取数据,一边要动态显示实时曲线或其他图形,再存入数据库或
其他数据库操作,多线程的使用是十分必要的.特别是数据传输速率大,数据库一次性操作纪录个数比较多的时候.

[multiplex]

我觉得你的分析还是比较正确的,读写数据库的时间肯定要长些,不过我不知道你的串口速率有多大,还是随机的,我以前用9600bps,再往Access里写,纪录就不成样子了.

[yrj]

在程序设计中，对是否要用多线程和要开多少线程要权衡利弊，

[iBreathe]

我不算前10个
只是关注

[twol]

关注

[sswz]

gz

[errorzhl]

确实如此，用户在使用多线程时，需要考虑它处理的内容的时间与多线程切换的时间之间的比值，另外，多线程还有一个问题，就是内存消耗非常晋严重。

[classfactory]

10

[repus]

本人认为
多线程的最大优点有二，一是利用多处理器的并行能力，这就不用说了。
二是简化编程，多线程一般用于处理多个I/O，用于计算的话在单处理器上得不到任何好处，在一个IO被阻塞时可以执行其他操作，其实大部分IO操作有相应的异步方式，不用多线程也可以避免被阻塞，但这样程序的控制结构就会复杂化，就好比递归算法的非递归实现。用多线程就可以简化为多个顺序控制流。

[temp]

<<另外，多线程还有一个问题，就是内存消耗非常晋严重。

是吗？不过，现在的内存这么便宜。。。

[temp]

<<其实大部分IO操作有相应的异步方式，不用多线程也可以避免被阻塞，

可是下一个操作要用IO操作的结果呀，还得等着。