|
|
首先，我将把win32多线程和协作多任务的优劣作个比较.
0) 优点:多线程代码编写方便,多线程程序不会把其他程序卡死
1) 多线程会搅乱数位, 但协作多任务不会
这点是很明显的，不过前提是，你代码逻辑合格,比如遍历list时,后面话不说了
2) 线程同步中存在对 CPU 的浪费，当CPU数量 < 线程数的时候
为了讨论方便先假定 CPU数量 = 1, 并且 "CPU" 指该应用程序的CPU时间
因为多线程会任意搅乱数位, 所以要进行线程同步, 而线程同步的话就存在一些等待,
而所有的操作实质上都是 并 行 地在 一 个 CPU中执行的. 那么这些等待时间中, CPU完全被浪费了
我们再看看协作多任务的情形, 协作多任务就是类似 module_iterater->Update() 这样的方式,
通过手工编码模拟多个任务的并行, 由于我们是用单线程的代码模拟的多任务,
所以不必担心物理上的win32线程同步问题 (只要你代码逻辑合格,比如遍历list时,略)
也就是说没有任何等待时间, 即CPU完全用来执行你程序中的多个并行任务.
3) 就算我不计较上述缺点, 但,win32多线程根本不划算 (游戏开发界)
我们广大的游戏开发世界, 需要编写大量的协作多任务代码, 我们知道协作多任务的代码比win32多线程的在编写上要麻烦点----我们现在牺牲了这点, 那么应该可以换来好处, 就是win32多线程的缺陷不存在了. 而事实呢？ 恐怕没有, 因为很多场合我们仍然离不开win32多线程, 比如动态场景加载等.
换言之, 我们用协作多线程写代码而做了牺牲, 同时却又要承受win32多线程的缺陷. 吃力不讨好.
下面，我们谈一谈问题的解决.
1) 协作多任务的代码编写起来不直观.
我想请问编译器做什么去了？这个小的转换工作菜鸟程序员也会写.
2) 就算有一个自动生成协作多任务代码的编译器, 但, 一些库函数是相当耗时的.
这是由于那些库函数不是协作多任务的, 所以会阻塞我们的程序.
但, 其实问题太简单了, 如果世界上没有win32多线程而只有协作多任务, 则一切库函数都是协作多任务的,
那么这个问题还存在吗?
3) “好吧, 但是, 楼主也要考虑考虑, 这样的话多少类库需要重编译成协作多任务的啊？"
初看起来的确有这个问题, 我们要想想看, win32有For win32版本的类库吧？
换句话说计算机界从16位升级到32位时已经作了类库版本的更换.
既然横竖都要更换类库, 就不必担心 "多少类库需要重编译" 这类问题了.
4) 协作多任务可能会把其他程序卡死
我们的编译器做什么去了？
此外别忘了CPU. 我们的CPU也可以限制“超时”（超时的话再去采取抢占措施）
原文出处 http://www.instemast.com/ |
|
发表于 2009-2-10 03:03:00
楼主