[资料] Concurrency in the D Programming Language
 |
hqs7636
2010-07-17
TANGO 不是说也要支持 d2 吗？ 怎么没动静了
|
 |
lifc
2010-08-06
hqs7636 写道 不会吧，这么差？还不如 go ？ go的并发是基于用户态的“微进程”（goroutine），和erlang以及lua的coroutine还有早年java的green thread概念相仿，但lua的coroutine不支持并发go却做到了（虽然阻塞调用os api或者lib api时处理有点麻烦）。 效率方面，因为是在用户态进行切换所以切换效率比用os线程的std.concurrency高，但只要不是用erlang那种思路去开发，通常多个并发绪之间的交互不会那么频密，所以只要设计得当也应该不会成为瓶颈。 其实d的tango和phobos（好像从tango移植过去的）都包含了Fiber类，原本就与go的思路相去不远，只是因为没有提供Fiber调度器所以应用范围并不广泛。 题外话：d的fiber切换需要保存的寄存器比较多，而go继承了Plan 9以及Plan 9 C编译器一贯风格，函数调用几乎看不到寄存器压栈（Ken早年还专门就此撰写过一篇paper加以论证）所以单就切换效率来说即便是d的fiber也未必是go的对手。 |
|
hqs7636
2010-08-07
那为什么 d 不用 go 的思路呢？是语言本身的原因还是别的什么问题？
|
|
lifc
2010-08-08
hqs7636 写道 那为什么 d 不用 go 的思路呢？是语言本身的原因还是别的什么问题？
这么多年d方向始终不明确，缺少清晰目标和思路，发展随意性比较高（打哪指哪类型），现有东西基本是个人兴趣堆积而来（比如W、A他们搞的Phobos，Tango社区的Tango，gdc、ldc编译器，还有dsources上面大量的遗留项目），高层对大方向把握力度欠缺，纠结细节时间比较多，错过了10年大好光阴。 每当别人问W并发怎么搞，得到的答案经常是XXX正在研究，XX也承诺过，只是还没出成果。这次的std.concurrency也是Sean Kelly在这种背景下毛遂自荐弄出来的，据说线程实现只是暂时的，将来(？)应该会更好…… 虽然对go目前所达到的效果还不太满意（代码效率、gc效率、不支持回调、“系统”语言不支持指针、官方尚未提供windows移植、gccgo重度残疾），但起码人家开发模式紧凑（开源想成功最好也要有工资发，几个成功的项目基本都具备这一特点），google groups上面一直非常热闹（虽然要翻.墙没事也过去看看），大大小小的革新一直紧张有序的在进行，这方面很值得d社群借鉴。 |
|
betty_betty2008
2010-08-09
lifc 写道 hqs7636 写道 那为什么 d 不用 go 的思路呢？是语言本身的原因还是别的什么问题？
这么多年d方向始终不明确，缺少清晰目标和思路，发展随意性比较高（打哪指哪类型），现有东西基本是个人兴趣堆积而来（比如W、A他们搞的Phobos，Tango社区的Tango，gdc、ldc编译器，还有dsources上面大量的遗留项目），高层对大方向把握力度欠缺，纠结细节时间比较多，错过了10年大好光阴。 每当别人问W并发怎么搞，得到的答案经常是XXX正在研究，XX也承诺过，只是还没出成果。这次的std.concurrency也是Sean Kelly在这种背景下毛遂自荐弄出来的，据说线程实现只是暂时的，将来(？)应该会更好…… 虽然对go目前所达到的效果还不太满意（代码效率、gc效率、不支持回调、“系统”语言不支持指针、官方尚未提供windows移植、gccgo重度残疾），但起码人家开发模式紧凑（开源想成功最好也要有工资发，几个成功的项目基本都具备这一特点），google groups上面一直非常热闹（虽然要翻.墙没事也过去看看），大大小小的革新一直紧张有序的在进行，这方面很值得d社群借鉴。 请问 C++ 0x 又是如何设计的？ |
|
lifc
2010-08-09
betty_betty2008 写道 请问 C++ 0x 又是如何设计的？ 据我所知c++0x并发相关的草案有几个，语言层面加入了多线程内存模型（参看Java 1.5）、线程本地存储、并发访问顺序点等规范，标准库则引入线程(池)、互斥和信号量同步、atomic原子操作（包括内存barrier）、async和future异步执行等机制。 async、future目前虽然还是基于os线程，但对c++来说仍可算巨大进步，最终情况要等标准发布才能看到，不过应该不会再有太大的变化。比较可惜的是gc暂时没加入，基本gc支持也未见动作，现在看跳票可能性比较高了。 |
|
hqs7636
2010-08-12
是线程库的问题还是并发库或者两者都有问题？？？
|
|
lifc
2010-08-14
hqs7636 写道 是线程库的问题还是并发库或者两者都有问题？？？
不知指的是c++还是d。就d本身来说或许并非某种技术运用、实现不到位那么简单，可以看看权威人士怎么说。 go语言google groups有个d和go的比较帖(GO VS D)，A大中间也几次到场发言，讨论到今天仍然在继续。前面部分侧重d和go特性比较（包括d所面临问题），感觉主要看点在帖子里的链接（如MiniD作者博客），有些要穿墙： http://groups.google.com/group/golang-nuts http://h3.gd/devlog/?p=22 http://www.jfbillingsley.com/blog/?p=53 后面A大14号发言，把话题转换向了Actor、CSP并发模型（虽然D号称两个都支持，但后面的页面失效n年了），并指出go实现的CSP模型的一些问题，Ian Lance Taylor对此还是用go的招牌外交辞令答复：通过消息而不是共享内存来通讯。 A大进一步指出，go的通道并未对消息类型进行限制，任何间接消息（指针）传递都可能带来潜在访问竞争（java、c++ 0x、d内存模型所要解决的问题），言外之意go的改革不彻底，内存访问一致性问题并未解决，所谓的消息共享只是半吊子（话外音这是我自己加的，不是A的原话），最后ILT老兄抛出go内存模型说明网址（go的所谓内存模型只提出lock、mutex之类的锁定机制，未包含明确内存屏障，虽然mutex可以作为重量级屏障使用）。 |
|
hqs7636
2010-08-15
主要是说d
Bartosz 这哥们搞的并发东东究竟好不好？ |
|
lifc
2010-08-17
hqs7636 写道 主要是说d
Bartosz 这哥们搞的并发东东究竟好不好？ 虽然并发概念的提出已经超过半个世纪，但究竟哪种方案最理想，恐怕至今还没有定论。 Bartosz提出的d并发设想，同样概念性的东西更多，如果实现需要对语言做一些大的改动（例如线程、内存、资源共享等模型），而在多数人看来目前这种改动对d来说可能过于激进。 Bartosz自己的思维跳动也较频繁，这一点从他的博客上可以看出。一个观点从提出到否定中间可能只有几个月的时间，这一方面说明他对并发的研究和探索从未停止（也就是没有成熟），但另一方面也给语言的实现带来更多的不确定性。 两篇相关blog： http://bartoszmilewski.wordpress.com/2010/05/11/parallel-programming-with-hints/ http://bartoszmilewski.wordpress.com/2010/08/02/beyond-locks-and-messages-the-future-of-concurrent-programming/ |
