在日益流行的语言中重新创建线程和并发知识

Question

我主要是一名Java开发人员，我一直在阅读有关线程和并发性的大量深入研究。许多非常聪明的人（Doug Lea，Brian Goetz等）撰写了有关这些主题的书籍，并为Java的新并发库做出了贡献。

当我开始更多地了解Python，Ruby和其他语言时，我想知道：是否必须为这些语言重新创建所有这些工作？

是否存在或者是否需要“Python的Doug Lea”或“Ruby的Goet Goetz”，他们对这些语言的并发功能做出了类似的强大贡献？

是否必须为将来的语言重新创建所有用Java完成的并发工作？或者用Java完成的工作是否会为未来的语言建立课程和指导？

Answer 1

并发编程的基本原则存在于java之前，并在您正在讨论的那些Java书籍中进行了总结。 java.util.concurrent库同样源自以前的代码和关于并发编程的研究论文。

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

所以，你可能需要一本书来教你在其他语言中使用并发工具的规范用法，但它不会重新发明轮子。

Answer 2

请记住，线程只是处理“并发”的几种可能模型之一。例如，Python在Twisted中拥有最先进的异步（基于事件）非线程模型之一。非阻塞模型非常强大，并且在大多数最高扩展应用程序中用作线程的替代方案（例如，nginx，lighttpd）。

您对其他流行语言需要线程的假设可能仅仅是以Java为中心（因此以线程为中心）的世界观的症状。请查看C10K页面，了解有关如何处理大量并发请求的几个模型的略微过时但信息量很大的信息。

Answer 3

我认为答案是肯定和否定。 Java可以说是最明确定义的内存模型和最常用的命令式语言（Java，C ++，Python，Ruby等）的执行语义。从某种意义上说，其他语言要么完全缺乏这种语言，要么正在追赶（如果在线程模型不成熟的情况下甚至可能）。

C ++可能是一个值得注意的例外 - 它一直在为C ++ 0x提供相同的基础，并且可能已经超出了我的印象中的Java模型的当前状态。

我说不，因为社区不是孤立的。许多从事这种工作的人都参与其中（至少从指导的角度来看，如果不是直接参与规范），不止一种语言。因此，在JMM和从事C ++ 0x规范工作的人之间存在很多串扰，因为他们基本上解决了许多相同底层驱动程序的相同问题（来自底部的硬件人员和最佳）。而且我很确定JVM / CLR阵营之间在某种程度上存在交叉谈话。

正如其他人所提到的，还有其他并发模型：Erlang和Scala中的actor，Clojure中的agent / STM，F＃中的FP，Scala，Haskell，CLR中的CCR和PLINQ等等。这是一个现在激动人心的时刻！我们可以使用尽可能多的并发专家，我认为.... :)

Answer 4

这不是火焰诱饵，但IMHO Java有一个更简单，更受限制的线程和并发模型。 这不一定是坏事，但是在粒度级别它提供它意味着它给你的并发性是什么以及如何处理它的视角本质上是有限的，如果你有一个“以Java为中心”的视图（就像其他人放的那样）它）。

如果您对并发性非常认真，那么值得精确地探索其他语言，因为存在不同的模型和习语。

一些最热门的领域是无锁编程（你会看到很多，但在C ++中经常做得很糟糕）和函数编程（已经存在了一段时间，但可以说，正变得越来越重要。并发情况下的一个主要例子可能是Erlang）。

Answer 5

Kamaelia是一个项目（我开始并继续工作），其目标是使并发成为您想要使用的工具，而不是使用的痛苦。实际上，这意味着它主要是一个没有共享模型的消息传递模型（基于Occam和Unix管道的世界观）。

这个目标的基础是希望使并发性易于为普通开发人员使用，从而使他们免受由多种并发方法引起的更糟糕的问题。 （关于幻灯片共享的一系列演示文稿解释了为什么以及如何）

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

Kamaelia的主要实现是在python中，在Ruby和Linux中使用玩具实现。 C ++。其他人已将基础方法移植到E以及Java。 （虽然Java人已经消失了）（玩具实现是完整性检查，这些想法可以用其他语言工作，如果需要重新制作为本地习语）

也许你的问题不应该是“这些语言能学到什么”，而是“Java社区可以通过寻找其他地方来学习什么？”。许多学习python的人都是来自其他地方的移民，并带着他们的其他语言的知识，所以从我坐的地方看起来像python已经注意到其他语言的灵感。

采用具体的东西，例如，this speak and write application - 这是一个基于笔输入，手写识别和语音合成器教小孩读写的工具 - 使用几十个并发子系统，运行于在单核机器上可接受的速度，很容易在多核机器上运行。但是，并发子系统数量的原因与“想要使应用程序并行”无关，而更多地与“如何使应用程序更容易编写，扩展和维护？”无关。 最终令人尴尬地平行的事实是次要奖励。

有一个完整的教程 - Pragmatic Concurrency - 从首页链接。 （注释，幻灯片，视频和代码包）

模型可以改进，欢迎提出建议 - 如果我们都“停止”试图制作更好的工具，生活将会非常无聊 - 但忽略已经存在的东西似乎有点......狭隘。如果这看起来有点刺耳，请查看today's dilbert。

： - ）