[资料] Concurrency in the D Programming Language
 |
hqs7636
2010-08-17
受教了，谢谢，
那何不把现成的几个东东的优点综合一下设计个东东出来不就好了吗？不会是想不到吧，暂时不用那么费劲去创新吧，费力不讨好 lifc 写道 内存访问一致性问题并未解决。
这东东难在哪里？ 在语言内部实现自动加锁、解锁呢？（启动一线程就加锁，结束线程就解锁，比如让gc来充当这部分虚拟机的功能）是不是就解决了？ |
 |
lifc
2010-08-17
hqs7636 写道 lifc 写道 内存访问一致性问题并未解决。
这东东难在哪里？ 在语言内部实现自动加锁、解锁呢？（启动一线程就加锁，结束线程就解锁，比如让gc来充当这部分虚拟机的功能）是不是就解决了？ 锁粒度大则并发效率低，粒度小需要注意的地方太多实现困难。所以现在并发的基本思想是尽量不让程序员手动写代码来控制锁，而是转为更为“自动”的方法实现，比如用CSP、Actor的消息传递模型（包括erlang的并发微进程+不可变数据）来将程序分割成多个独立的执行序。 但相对erlang这种不可变数据机制，c++、d、go等语言无论采用Actor还是什么消息模型，都无法回避内存访问一致性问题，就是说a线程顺序写入x、y两个变量，b线程（同步运行在另外一个cpu或者核心）看到的x、y变量变化的顺序可能与a线程写入顺序不同（其实是cache一致性问题），经典的DCL（Double Check Lock）问题就是这样产生的。 d围绕这个问题，提出了一系列的解决方案，包括d2里的shared、默认tls存储模型等诸多麻烦都像打开潘多拉盒子一样一发而不可收拾。 d的几位大牛产生分歧的地方也恰恰就在这里，有人认为语言应该自动决定哪些数据受shared影响（比如shared结构体内的数据自动继承shared属性），另外一些人则认为此种方法杀伤力太大，因为一次内存一致性操作（读、写屏障）代价可能是几百甚至上千个指令周期。 |
|
hqs7636
2010-08-17
哦，明白了，那 cpu 和 os 到目前有什么作为吗？这么看来应该是他们的事，特别是 cpu 应该提供专门的指令那就简单了
|
|
lifc
2010-08-18
hqs7636 写道 哦，明白了，那 cpu 和 os 到目前有什么作为吗？这么看来应该是他们的事，特别是 cpu 应该提供专门的指令那就简单了
OS给我们提供了同步锁，为了高效实现，其中用到CPU的一些特殊指令集（主要是原子操作指令）。另外从SSE、SSE2开始支持内存屏障指令，LFENCE、SFENCE、MFENCE，可以提供比lock xchg更精细的内存屏障操作，但开销同样比较大。 虽然有这些同步机制，但要求普通开发者完全了解CPU、Cache的工作机制（不同厂商、时代的处理器尚存在差异）并在每个变量赋值前后都小心谨慎的加锁或同步并不现实，所以当前这一重任就落到了具体开发语言身上，大家都在探索寻找一种模型，可以降低并发编程的复杂度，提高代码编写时、运行时的效率。 |
 |
Colorful
2010-08-18
关于并发这一块，业界也探索了多年了，还是没有银弹。
要想很好的写出并发程序，计算机硬件体系和操作系统的构造还是必须要了解清楚。 Intel 针对 C++ 的 TBB 和 Microsoft 的 Concurrent Runtime 以及 Parallel Extension for .NET 我觉得都是不错的尝试。很多计算密集型的任务在这里都可以大大得到简化。最近正在了解 DirectCompute ，异构编程很可能会是未来的趋势所在。 顺便推荐一本并发的好书：《Windows 并发编程指南》，Joe Duff 的大作。 |
|
hqs7636
2010-08-18
感谢两位大侠不厌其烦的指点，好像有点明白了，感谢！
《Windows 并发编程指南》有电子版吗？买了可能也是浪费，不一定看得懂，只能是大致了解一下 win api ， win mfc 龙书等，n多年了还是新的 
|
|
betty_betty2008
2010-08-23
lifc 写道 hqs7636 写道 哦，明白了，那 cpu 和 os 到目前有什么作为吗？这么看来应该是他们的事，特别是 cpu 应该提供专门的指令那就简单了
OS给我们提供了同步锁，为了高效实现，其中用到CPU的一些特殊指令集（主要是原子操作指令）。另外从SSE、SSE2开始支持内存屏障指令，LFENCE、SFENCE、MFENCE，可以提供比lock xchg更精细的内存屏障操作，但开销同样比较大。 虽然有这些同步机制，但要求普通开发者完全了解CPU、Cache的工作机制（不同厂商、时代的处理器尚存在差异）并在每个变量赋值前后都小心谨慎的加锁或同步并不现实，所以当前这一重任就落到了具体开发语言身上，大家都在探索寻找一种模型，可以降低并发编程的复杂度，提高代码编写时、运行时的效率。 老大能也评评D2 的PHOBOS 库在语言发展，新多核时代工业、市场新需求下的价值或是地位吗 |
|
lifc
2010-08-24
这题目似乎有点大了，不知道Andrei Alexandrescu能不能说明白：）
个人人为，D2的并发特性基本上还在探索阶段，Phobos并发相关的除了传统的thread、fiber外就只有std.concurrency这个模块。std.concurrency用D灵活的模板机制实现了erlang选择性接收和spawn，离真正实用恐怕还有点距离。
最近A大比较活跃，影响力似乎慢慢盖过了W大，希望他能在并发方面提出一些新思路，不要光惦记着折腾模板。
|
|
betty_betty2008
2010-08-24
lifc 写道
这题目似乎有点大了，不知道Andrei Alexandrescu能不能说明白：）个人人为，D2的并发特性基本上还在探索阶段，Phobos并发相关的除了传统的thread、fiber外就只有std.concurrency这个模块。std.concurrency用D灵活的模板机制实现了erlang选择性接收和spawn，离真正实用恐怕还有点距离。最近A大比较活跃，影响力似乎慢慢盖过了W大，希望他能在并发方面提出一些新思路，不要光惦记着折腾模板。
|
|
lifc
2010-08-25
betty_betty2008 写道
这个问题是有点大，但也是困惑已久的问题，为什么我选择D？仅仅是因为语法优雅吗？不太甘心，还得指望它有竞争力。 这也是我一直在问自己的问题。 接触d差不多10年，其间用它做过几个项目，给我的印象是带来的麻烦超过获得的便利。 后来想想，继续用c++算了。虽然写代码慢点，编译慢点，可执行文件大点……但起码基础稳固容易维护，开发和调试都没有障碍，而且随着c++0x标准出台以及新语言的不断涌现，d的优势已经远没有10年前那么明显。 不过还是认为，d绝对值得关注，特别是A大的高调介入更给人留下丰富的想像空间。
|
