单cpu的机器, 多进程编程和多线程编程有多大优势?

flw

原帖由 cugb_cat 于 2008-1-21 17:32 发表
习惯吧,我也说不出理由来

哦，这样啊。

cugb_cat

线程比进程操作共享数据比较容易,比如,一个共享的标志(好像处理器可以保证对一个变量赋值的原子性?),如果用进程通信  麻烦死了感觉.

flw2

原帖由 flw 于 2008-1-21 17:11 发表

我写脚本语言一般也不怎么调试，print 基本上是跨语言跨平台最好的调试方法了，对于某些特殊情况，不能用 print 的（比如遭遇测不准原理时）可以用计数器调试。

但是对于 C 程序来说，
ltrace 查程序流程 ...

我一般也是strace + printf(越来越少了，现在通常有个宏取代它，安置一个开关 )
gdb用熟悉肯定是好处多多，不过我还是懒的学习，感觉也没有printf和strace来的快
v*也一样不会用，看着一堆输出和参数，不想学

flw

原帖由 cugb_cat 于 2008-1-21 17:37 发表
线程比进程操作共享数据比较容易,比如,一个共享的标志(好像处理器可以保证对一个变量赋值的原子性?),如果用进程通信  麻烦死了感觉.

晕。又来了。死循环了。

ivhb

原帖由 cugb_cat 于 2008-1-21 17:37 发表
线程比进程操作共享数据比较容易,比如,一个共享的标志(好像处理器可以保证对一个变量赋值的原子性?),如果用进程通信  麻烦死了感觉.

必须是 sig_atomic_t 吧

HbbT

1.如果有自己的平台,有自己的shell.调试的时候直接打开log,看shell输出.
2.gdb断点调试多线程很方便呀.
3.多进程开销比多线程大.

cugb_cat

原帖由 ivhb 于 2008-1-21 18:38 发表

必须是 sig_atomic_t 吧

恩，应该是，不过我在看一本书的时候（忘记哪本了）说有的处理器保证对变量赋值的原子性？记不太清了。

cugb_cat

原帖由 flw 于 2008-1-21 18:05 发表

晕。又来了。死循环了。

apollolegend

多线程对操作系统来说意义是很重大的（单CPU也一样），对于不同的任务类型，操作系统可以进行适当的调度以提高CPU的利用率
对于多线程来说，任务的类型是很关键的，有的任务是CPU密集型的任务，如计算任务，有的任务是IO密集型的任务，如数据采集等，多线程就可以保证CPU处于高利用状态。如果任务因ＩＯ操作而挂起，那么其他任务将得到ＣＰＵ，从而提高ＣＰＵ的利用率

从编程的角度来说，应该把你的任务进行适当的分类，可并行执行的部分当然要用多线程来实现，这是不应该有争议的，比如为每个采集通道配置一个软滤波线程，而不是所有的通道使用一个线程，这更符合现实情况。

个人认为多线程的目的主要有二
１）提高cpu的利用率
2）尽量减小线程的粒度，提高程序的并行性