关注STM(software transactional memory)
收藏
翻看孟岩的这篇讲C/Java的文章（http://blog.csdn.net/myan/archive/2007/01/14/1482614.aspx） 的时候，看到 pongba 批阅关于C/Java的concurrent问题的回帖中提到：
”C语言中的并发编程问题是源于语言对多线程内存模型没有内建支持，从而使得编写可移植的多线程程序变得不可能。C++也有同样的问题，不过C++社群正在积极解决。
除 此之外，在C里面编写多线程程序和在Java里面一样，因为Java的内存模型也只是传统的Lock-based。Lock-based模型众所周知的问 题就是粒度粗了会损伤效率，粒度细了又容易导致死锁。所以使用lock来编写并发程序是件非常tricky的事情。Java只不过提供了一些方便一些的 库，如lock-free的ConcurrentHashMap，除此之外，没有本质区别。
另一个很有前景的并发机制就是STM（software transactional memory），目前在haskell等一些FPL中得到了初步实现，不过由于这个领域目前还是比较不够成熟（与lock-based相比），所以大规模投入商业应用估计还要一段时间。
此 外，C语言的抽象机制简单与并发编程并无多大关系。实际上支持并发编程模型的语言如Java在语言层面也支持提供一点简单（虽然很tricky）的支持， 从而让编译器能够“知道”多线程的存在;更高层的抽象仍然是由库来完成。所以把这个问题归结到语言的抽象层次上似乎不够准确。“
看来这个STM还是很有看头的，下一步进行关注，呵呵。
”C语言中的并发编程问题是源于语言对多线程内存模型没有内建支持，从而使得编写可移植的多线程程序变得不可能。C++也有同样的问题，不过C++社群正在积极解决。
除 此之外，在C里面编写多线程程序和在Java里面一样，因为Java的内存模型也只是传统的Lock-based。Lock-based模型众所周知的问 题就是粒度粗了会损伤效率，粒度细了又容易导致死锁。所以使用lock来编写并发程序是件非常tricky的事情。Java只不过提供了一些方便一些的 库，如lock-free的ConcurrentHashMap，除此之外，没有本质区别。
另一个很有前景的并发机制就是STM（software transactional memory），目前在haskell等一些FPL中得到了初步实现，不过由于这个领域目前还是比较不够成熟（与lock-based相比），所以大规模投入商业应用估计还要一段时间。
此 外，C语言的抽象机制简单与并发编程并无多大关系。实际上支持并发编程模型的语言如Java在语言层面也支持提供一点简单（虽然很tricky）的支持， 从而让编译器能够“知道”多线程的存在;更高层的抽象仍然是由库来完成。所以把这个问题归结到语言的抽象层次上似乎不够准确。“
看来这个STM还是很有看头的，下一步进行关注，呵呵。
发表于 @ 2007年04月03日 08:38:00 | 评论( loading... ) | 举报| 收藏
旧一篇:haskell的世界观(2) | 新一篇:用haskell实现select的timeout（待解决）
- 查看最新精华文章 请访问博客首页相关文章
-
- 发表评论
-
- 表 情：
-
- 评论内容：
- 用 户 名：