.NET 的高级多线程/并发抽象答案

【问题标题】：High-level multithreading/concurrency abstractions for .NET.NET 的高级多线程/并发抽象
【发布时间】：2010-12-17 14:06:23
【问题描述】：

我只是想知道为什么与 Scala、F# 或 Haskell 不同，基本的 .NET 框架（在 C# 或 VB 中可用）似乎对更高级别的并发模式几乎没有原生支持。

有可用的基本机制——锁、监视器、线程池——但是呢

同步变量 (MVar)
同步频道
异步通道（参见 Go 或 Haskell）
参与者/消息传递 (Erlang-Style)
期货
并行计算/列表函数
通过 Linq 进行可组合的异步计算（如 F# 的 async {}）

甚至是软件事务内存 (STM for Haskell)

即使考虑到 ParallelFX，这个列表也只是部分覆盖。

是否有某些更深层次的理由反对提供此类功能（而是希望人们搞乱IAsyncResult's），还是计划在未来集成？

【问题讨论】：

您的列表中有大量的功能重叠。我认为我什至不想在一个环境中实现所有这些。
一方面，与您的示例语言不同，.NET 框架在设计时只考虑了面向对象的范式，Scala 是多范式，F# 和 Haskell 是函数式
@SpaceghostAli - 你怎么能说 .NET 只是为面向对象的范例而设计的，然后马上说 F#（一种在其上运行的语言）是功能性的？另外，您是否忘记了像 Linq 这样专门为允许函数式编程而设计的东西？
@Greg Beech - 如果您听 Anders 谈论为 .Net 设计诸如 Linq 之类的东西所面临的挑战，您就会明白我怎么说。 F# 团队还在几个 C9 视频中讨论了类似的挑战
@SpaceghostAli：如果 .NET 在设计时只考虑 OOP，它就不会有尾调用、闭包和泛型。

标签： .net concurrency functional-programming

【解决方案1】：

我同意 Greg D 的观点，未来会有很多“东西”。 MS 使用新的 .Net4 框架和他们的 Axum 项目。我看到所有这些方法的问题是它们变得非常复杂，并且分布式/并行/分布式计算领域的技能、知识和经验相当“有限”。我写这些不是为了冒犯任何人，但我认为大学和教育工作者通常必须更多地关注这些话题。但是，我认为和希望的是，MS 通过实施这些想法、Axum、CCR&DSS、异步代理库等创造的主流意识以及对多核/云计算机系统的总体趋势/需求，我们将看到很快:)

【讨论】：

现在您可以看到并触摸到 Axum 正在成为主流的部分，您是否仍然认为它们非常复杂（可能比使用支持它们的原语更复杂）？

【解决方案2】：

目前正在积极和持续地研究最佳和最有效的抽象，这些抽象可用于启用并发软件，而无需掌握大多数开发人员要么没有时间或没有意愿将他们的技能发展到那个水平的细节。

鉴于此，BCL 对新概念的进入门槛相当高，但这并不意味着它们不会发生。最近，在 .Net 4 中，将引入 Task Parallel Library。 TPL 的早期版本实际上是 included a Future<T> type，此后已被 newer abstractions 取代。

通过研究语言Axum，在渠道/等领域也正在进行积极的研究。

我显然不是团队的一员，也不为 Microsoft 工作，但我的理解是，除了已经广泛使用的领域之外，我还希望在该领域进行创新。

【讨论】：

TPL 用于并行性，而不是并发性。
没错。 Axum 是并发研究，其中获胜的概念现在（显然）被纳入 .Net 4.5。