2007-04-03旧作。原载:http://blog.csdn.net/st_monad/article/details/1550065
翻看孟岩的这篇讲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还是很有看头的,下一步进行关注,呵呵。