用越来越流行的语言重新创建线程和并发知识

并发编程的基本原理在java之前就已经存在了,并且在您所讨论的java书籍中已经进行了总结。这个java.util.concurrent这个库类似地是从以前关于并发编程的代码和研究论文中派生出来的。

但是,有些实现问题是Java特有的。它有一个指定的内存模型,并且Java中的并发实用程序是根据这个模型的具体情况而定制的。经过一些修改,可以将它们移植到具有不同内存模型特性的其他语言/环境中。

因此,您可能需要一本书来教您在其他语言中并发工具的规范用法,但这并不是在重新发明轮子。

请记住,线程只是处理“并发”的几种可能模型之一。例如,在大多数基于线程的Python模型中,最高级的是基于事件的异步(non-threaded)模型 Twisted . 非阻塞模型非常强大,并且在大多数最高规模的应用程序(例如nginx、lighttpd)中被用作线程的替代品。

您认为其他流行语言需要线程的假设可能只是以java为中心(因此也是以线程为中心)的世界观的一个症状。看看 C10K

我认为答案是肯定和否定。java可以说是最常用的命令语言(java、C++、python、Ruby等)中最明确定义的内存模型和执行语义。从某种意义上说,其他语言要么完全缺乏这一点,要么正在迎头赶上(如果考虑到线程模型的不成熟,这是可能的)。

C++可能是一个显著的例外——它为C++ 0x踩下了同样的基础,并且可能超出了我印象中的java模型的当前状态。

我说不,因为社区不是孤立的。很多从事这方面工作的人都涉及到不止一种语言(至少从指导的角度来看,如果不是直接参与规范的话)。因此,在JMM上工作的人和C++的X规范上的人之间存在很多串扰,因为它们基本上解决了许多与底层驱动程序相同的问题(从底层的硬件人员和顶部的用户)。我很确定JVM/CLR阵营之间也存在某种程度的串扰。

正如其他人提到的,还有其他并发模型:Erlang和Scala中的actors,Clojure的agents/STM,FP在F#中的崛起,Scala,Haskell,CLR land中的CCR和PLINQ等。现在是一个激动人心的时刻!我们可以使用尽可能多的并发专家。。。。:)

这不一定是坏事,但在它提供的粒度级别上,这意味着如果您有一个“以java为中心”的视图(如其他人所说),那么它提供的关于什么是并发以及如何处理它的透视图本身就受到限制。

如果您是认真对待并发的,那么有必要精确地研究其他语言 因为 存在不同的模式和习惯用法。

Kamaelia 是一个项目(我已经开始并将继续致力于此),它的目标是使并发成为您想要使用的工具,而不是一个很难使用的工具。实际上,这意味着它主要是一个无共享的消息传递模型(基于Occam&Unix管道的世界观)。

这一目标的基础是希望让普通开发人员更容易地使用并发性,从而使他们免受由许多并发方法引起的更糟糕的问题的影响。(slideshare上有一堆演示文稿,解释了为什么要这样做以及如何做)

此外,它还为必须共享数据的情况提供了一个简单的软件事务性内存模型,并使用了一个有意简化的API。

KAMAELIa的主要实现是Python,Ruby & C++中有一个玩具实现。其他人已经将底层方法移植到E和Java中。(尽管Java人已经消失了)(玩具实现是健全的检查,如果需要重新设计为本地习惯用法,这些思想可以在其他语言中工作)

比如说,挑一些具体的东西, this speak and write application -这是一个教小孩子读写的工具,基于笔输入、手写识别和语音合成——使用几十个并发子系统,在单核机器上以可接受的速度运行,很容易适应在多核机器上运行。然而,并发子系统数量的原因与“希望使应用程序并行”无关,而是与“如何使应用程序更易于编写、扩展和维护?”有关。 事实上,它最终令人尴尬地平行,这是第二个好处。

Pragmatic Concurrency -从头版链接。(笔记、幻灯片、视频和代码包)

模型可以改进,建议是受欢迎的-如果我们都只是“停止”尝试制造更好的工具,生活将是非常无聊的-但是忽略已经存在的似乎有点。。。狭隘的。如果这看起来有点苛刻,请看看 today's dilbert .