|
锁定老帖子 主题：多线程是个不靠谱的东西
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-06
如果把cpu的设计跟软件的设计比较一下 可以发现cpu从一开始（80年代起）就把并发放到生死攸关的位置 设计一个cpu很大程度上是想尽办法同时发起更多的计算 cpu的道路也一直都是向着增加流水线的方向前进 并为此付出很多代价 譬如mips下指令长度是一样的
而软件好像才刚刚苏醒 意识到并发的必要性 所以软件落在了cpu后面 借鉴一下cpu设计的思路的话 或许可以得出结论 并发是一个必须从一开始就考虑的问题 不存在平滑的从顺序过渡到并发的算法/思路 |
| 返回顶楼 | |
|
发表时间：2008-05-06
引用 借鉴一下cpu设计的思路的话 或许可以得出结论 并发是一个必须从一开始就考虑的问题 不存在平滑的从顺序过渡到并发的算法/思路
如果存在咋办涅？？？ |
| 返回顶楼 | |
|
发表时间：2008-05-06
Trustno1 写道 引用 我们不缺工具，但缺best practise
面对并行，我们现在缺的就是工具 我觉得工具还不是问题,是缺少一种思考方式. 面向Task的思考.. |
| 返回顶楼 | |
|
发表时间：2008-05-06
还有 如果erlang的方法是自己维护自己的线程 从而避免上下文切换
那么这种工作很早就有了 譬如bsd的lth 事实上 thread的实现一直都有各种实现 包括在os里面实现的 也包括在user space实现的 只不过linux喧嚣尘上的气势让一对一模型大行其道 连solaris都向这个方向靠拢 而bsd那种模型则只在些老应用上采用 |
| 返回顶楼 | |
|
发表时间：2008-05-06
ray_linn 写道 Trustno1 写道 引用 我们不缺工具，但缺best practise
面对并行，我们现在缺的就是工具 我觉得工具还不是问题,是缺少一种思考方式. 面向Task的思考.. 恩这种思考方式不能说不对，但是还是粒度的问题。 在更小的粒度上以这种方式思考就会陷入误区. |
| 返回顶楼 | |
|
发表时间：2008-05-06
Trustno1 写道 引用 借鉴一下cpu设计的思路的话 或许可以得出结论 并发是一个必须从一开始就考虑的问题 不存在平滑的从顺序过渡到并发的算法/思路
如果存在咋办涅？？？ 那就学咯 |
| 返回顶楼 | |
|
发表时间：2008-05-06
Parallel C#是种更有意思的方案,它可以在function面前加上"同步" "异步" "可移动" 的关键字,对思考来说更有意义.
|
| 返回顶楼 | |
|
发表时间：2008-05-06
ray_linn 写道 Parallel C#是种更有意思的方案,它可以在function面前加上"同步" "异步" "可移动" 的关键字,对思考来说更有意义.
这个放案，很难解决这样的问题. 引用 首先我排除了大部分的文件读写操作，顺序读取会导致文件指针的移动，这显然会导致不确定数据结果，特别是要把数据填充到一系列结构（Struct)中去的时候，多线程产生了一堆错误的结果。
|
| 返回顶楼 | |
|
发表时间：2008-05-06
Trustno1 写道 ray_linn 写道 Parallel C#是种更有意思的方案,它可以在function面前加上"同步" "异步" "可移动" 的关键字,对思考来说更有意义.
这个放案，很难解决这样的问题. 引用 首先我排除了大部分的文件读写操作，顺序读取会导致文件指针的移动，这显然会导致不确定数据结果，特别是要把数据填充到一系列结构（Struct)中去的时候，多线程产生了一堆错误的结果。 别卖关子了 指条明路吧 |
| 返回顶楼 | |
|
发表时间：2008-05-06
Trustno1 写道 ray_linn 写道 Trustno1 写道 引用 我们不缺工具，但缺best practise
面对并行，我们现在缺的就是工具 我觉得工具还不是问题,是缺少一种思考方式. 面向Task的思考.. 恩这种思考方式不能说不对，但是还是粒度的问题。 在更小的粒度上以这种方式思考就会陷入误区. 指令并行？在现有的架构上根本无法实现。 操作系统以线程做最小的调度单位， 单个CPU需要做任务状态切换，多个CPU之间寄存器不共享。指令乱序，流水线这些设计对软件是透明的，你一个用户态程序怎么做指令并行？ 还是老老实实做好设计更实际。 |
| 返回顶楼 | |
