win32多线程模式的缺陷与解决

lcy03406

楼主是想把大家拉回解放前，然后他好发明电脑

instemast

stephen_z: Re:win32多线程模式的缺陷与解决

那你到底是想说多任务还是并行计算的好处呢? 别忘了,即使是并行算法,其中每一个节点上也是有串行成份的.

1 第#1楼说的是 多任务 优于 多线程 （但这些都是串行计算世界的并行把戏）
  而后面又顺带提了， 真正的并行计算世界 优于 串行计算世界的并行把戏

2 别忘了，即使是win32多线成，其中每一个thtead上也是有串行成份的.

stephen_z

现代编译工具己能将指令并行化,按照CPU数量将多线程计算均匀分配到每一个CPU上.也只有实现多线程的程序,才能将并发计算分配划分到更小的粒度,并有更小的任务切换所需要的开销.

多线程没有复杂的安全性检验,没有耗时的内存复制与任务上下文切换(如果你学过编译原理话,应该知道多线程与多任务用到的栈是不同的),二者的效率是相差不只一个量级.现在再谈用多任务取代多线程,那是拿冷兵器和对方的火器硬拼,是技术和历史的倒退.足以让人贻笑大方.

instemast

stephen_z: Re:win32多线程模式的缺陷与解决

现代编译工具己能将指令并行化,按照CPU数量将多线程计算均匀分配到每一个CPU上.也只有实现多线程的程序,才能...

笑死人了。
怎么会有粒度问题？（如果所有类库都是这样的话！）

6spring

自己的分时系统是可以模拟出“多线程”的效果，但是问题核心在于，多线程的应用范围和分时多任务完全不相同。多线程一般用在慢速阻塞操作（如IO、网络）方面，甚至你自己都发现它有自己独特的应用处（如地形加载）。此外，现在CPU都是双核、四核、N核，服务器上更是多CPU，不使用线程才是真正的浪费（多进程协作处理除外）。

而自己实现的分时系统，最难处理的就是任务时间片分配问题，对于OS来说，实现这种时间片分配，是它的本职工作，得心应手，所以它提供了一个轻量级的线程，重量级的进程。

此外，更换类库，不是说想换就好换的，我估计你是没做过实际项目吧，几十几百万甚至几千万行的代码，有些可能已经用了10几年，原本开发人员早已离开，要去重新重新整理一遍不是那么容易的，而且还要考虑老版本的兼容问题。比如说64位平台操作系统，出来那么多年，优势很明显，但为啥长时间不普及，兼容性就是一个大问题，也是经过好些年的修补才能达到目前的少量不兼容，而且64位说明白一点，对于普通开发人员最主要的改变只是int从32位变成64位而已，看似小改动，但是带来无穷的麻烦，更别说所有类库全部变成异步分时了...

我个人的习惯：主逻辑，消息任务驱动多任务；慢速阻塞操作，多线程；稳定性要求高于速度要求，多进程。
此外，建议线程都采用 “接受数据包 -> 独立处理 -> 吐出数据包” 的模式工作，中间不要和其他任何线程直接交互，这样可以避免很多的麻烦（不要和我说加锁，锁多了，调试逻辑死锁能让你吐血）

stephen_z

instemast: Re: Re:win32多线程模式的缺陷与解决



笑死人了。
怎么会有粒度问题？（如果所有类库都是这样的话！）

呵呵,不同的C++编译器,不同的操作系统,实现多线程的方式差别很大,你写过,调试过多线程的代码没有?.

instemast

我说的很清楚，协作多任务不存在粒度问题 ---- 只要调用的所有类库都是这种方式！
如果你的类库不重编译，我觉得这个问题就没有意义了。

此外，更换类库，不是说想换就好换的，我估计你是没做过实际项目吧，几十几百万甚至几千万行的代码，有些可能已经用了10几年，原本开发人员早已离开，要去重新重新整理一遍不是那么容易的

0) 我不一定要用那些类库的功能
1) 随着时间的推移,谁能找到10年前的代码？ 所以说总会淘汰的更换的
2) 我文章说了，从win16-win32已经存在着类库的更换了
3) 如果说难换,那么现在的3DModel呢？通用性那么低，天天都要转换，这又怎么说呢？
5) 2000年问题怎么解决的？----全换，而且是硬件！
   乱码问题解决的过程是怎么样的？----vb6是COM,内部是uc结果还是外部还是乱码。
   这都是腐败。

对于普通开发人员最主要的改变只是int从32位变成64位而已，看似小改动，但是带来无穷的麻烦

这是设计模式，架构的问题。
----你都承认有这种问题（就是改动一个就要改动全部）。

6spring

兄弟，看来你还不如自己写一OS，反正线程、进程对于OS来说原本就是多任务分时系统而已，恐怕最后你写到最终实现，发现你的分时系统，在使用时基本和线程没啥太大区别....

线程为什么要同步和互斥？归根结底，就是时间片分配、操作超时强制让出资源造成的。

任务A正在处理一组数据，做了一半，时间片用完了，被强制中断，将CPU资源让出给任务B，此时B要使用A处理的结果，但是数据被A处理到了哪一步是无法预知的（可能处理完了，也可能没有，也就是你所谓的“多线程会任意搅乱数位”<好古怪的说法>），矛盾产生了，通行做法，就是检测一下A是否做完，没有的话，等待A的完成（进入锁状态，休眠让出CPU资源，A完成后再被激活），这就是互斥等待。而同一进程的多线程是共用同一内存地址空间，所以这种冲突更加的激烈。

感觉你似乎不是科班出身，也没有读过OS的相关书籍，不妨找来看看任务调度部分，就算看不起那些OS已经提供好的“破烂”功能，相信也可以学到如何写好自己的分时系统

很多事情，嘴上说说没有意义，真动手干了才知道，我算不上什么砖家叫兽，但是4年多写了约20几W行的有效代码，让我也明白了很多，事物往往只能逐步渐进式发展，一蹴而就带来的是更多的麻烦，甚至会导致严重后退。

PS：楼上和LZ争论的朋友其实不要和他争了，他说的多任务是自己的分时系统级，不是你认为的进程级协作多任务，所以你和他说粒度，他完全搞不清楚状况。

PS：你所谓的类库原来都是说自己写的类库啊，看来你总有一天需要把CRT库全部自己实现一遍的，呵呵

PS：看待过去的事物，抱着怀疑的态度去审视没什么，但请明了一点，请注意知晓其产生的历史背景和特定环境，否则就是个愤青而已。如果自己有意愿改变它，那就从自己做起，动手开干，拿出个成品比什么都有说服力，只知道抬着大嘴巴嚷嚷，永远都被人看不起。

PS：不再回复此帖

draculamx

每次 instemast 一发帖，都会引来热火朝天的论战啊。。。
好。。。虽然，我只是对WIN32下的多线程有着非常肤浅的了解，但这也不妨碍我欣赏大家精彩的论战。。。
真理就是在不断的推翻与重构中产生的啊。。。
大家继续，我技术菜，插不上嘴，继续观战。。。

instemast

反正线程、进程对于OS来说原本就是多任务分时系统而已

对呀，那你我的观点不是一致的吗？
你自己也承认了这个事实：
只有一个CPU的话，多线程和协作多任务，其CPU中执行的指令，
不都是基本一样的吗？（只是前者比较粗暴点,这不好）
即粒度最小可以达到1指令。
那么我想问：怎 么 会 有 粒 度 问 题 ？ （前提是所有代码都是协作多任务的）

那么细节上说。两者不同在何处呢？看下文：

“任务A正在处理一组数据。。。。。。所以这种冲突更加的激烈”
---- 这个问题，在协作多任务模式下，不存在（只要代码逻辑合格）。

“拿出个成品比什么都有说服力”
有成品的，而且，早就被人类制造出来了，就是协作多任务。