问题标签 [ccr]

我有兴趣比较各种可扩展性和并发性方法，包括 CCR 和 DSS 框架模型。我会对与 Hadoop 和 Erlang 风格的并发性进行比较特别感兴趣

不清楚这里是否有 ccr 大师，但我们还是试试吧。

我的代码中有这个功能：

dq.EnqueueTimer(TimeSpan.FromMilliseconds(TIMEOUT), timeOutFn);

这将在超时后调用我的函数。但是，由于我在很多打开的套接字上都需要这个计时器，所以我想将一个参数（或 ID）传递给计时器函数。

你怎么做到这一点？

谢谢

R

有一组长时间运行的离散任务：从文本文件中解析成千上万行、水合为对象、操作和持久化。

如果我在 Java 中实现它，我想我可能会为文件中的每一行或每 X 行（即块）中的任务添加一个新任务到 Executor。

对于我正在使用的.Net，我不太确定。我怀疑 CCR 在这里可能是合适的，但我对它不够熟悉，这就是我提出这个问题的原因。

CCR 能否以与 Java Executors 等效的方式运行，或者还有其他可用的功能吗？

谢谢

我想在使用 CCR 的项目中实现任务执行超时。基本上，当我将项目发布到端口或将任务排入 DispatcherQueue 时，我希望能够中止任务或其运行的线程，如果它花费的时间超过某个配置的时间。我怎样才能做到这一点？

Microsoft 的并发和协调运行时从字面上拯救了一个遇到重大死锁问题的项目。从那时起，我发现我越来越频繁地使用它来处理几乎所有需要异步编码的事情，从而产生比以前更轻、更快的结果。老实说，它改变了我对多线程/多核开发的看法。尽管我个人很喜欢 CCR，但在网络上似乎很少有关于它的嗡嗡声，我想知道是否有人可以为此提供任何理由。是否有更好的选择，或者是缺乏 MS 的推广，还是人们只是对现有工具感到满意？

拥有复杂的任务序列，在PortSet<ActualResult, Exception>为每个小任务使用 try/catch 块和诸如选择接收器之类的东西时，实现错误处理会很快使代码膨胀。

值得庆幸的是，CCR 似乎提供了一种机制来以更通用的方式处理任务图的异常：因果关系。一个典型的例子如下所示：

在我的例子中，我有一个计算密集型应用程序，它使用 CCR 来实现分散/聚集场景，将“作业”拆分成一堆并行化的任务。（除此之外，这些作业中的一个以上可以同时运行。）如果一个任务失败，我想停止该作业中的所有剩余任务，而不是任何其他作业。（如果我遗漏了一块拼图，结果对我毫无用处，所以继续努力只会浪费 CPU 时间。）

问题是实施停止的最佳方法是什么。

一个想法是：

1. 创建一个Dispatcher实例并在应用程序生命周期内保留它。
2. DispatcherQueue为每个“工作”（一组任务）创建一个新的。Causality创建后立即添加DispatcherQueue.
3. 在异常队列的处理程序中，调用Suspend().DispatcherQueue
4. 在处理调度程序队列之前，删除因果关系。

我想知道这个建议是否可以被视为最佳实践，或者是否有更好的方法来处理这种 - 可能相当普遍 - 场景。

我正在使用并发和协调运行时，并且正在编写类似于文档中描述的代码。以下行无法编译：

编译器给出此错误消息：

这是令人困惑的，因为文档使用带有类型参数的该方法，并且它显然是通用的。

（我将在这里发布我自己的答案，据我所知这是鼓励的）

我通过端口和接收器将 15 个异步操作链接在一起。这让我非常关心线程间消息传递时间，特别是从任务将数据发布到端口和新任务开始在不同线程上处理相同数据之间的时间。假设每个线程在启动时处于空闲状态的最佳情况，我生成了一个测试，该测试使用秒表类来测量来自两个不同调度程序的时间，每个调度程序都以最高优先级运行单个线程。

令我惊讶的是，我的开发设备是一台运行 Windows 7 x64 的 Q6600 四核 2.4 Ghz 计算机，我的测试的平均上下文切换时间为 5.66 微秒，标准偏差为 5.738 微秒，最大值接近 1.58 毫秒（ 282 倍！）。秒表频率为 427.7 纳秒，所以我仍然远离传感器噪音。

我想做的是尽可能减少线程间消息传递时间，同样重要的是，减少上下文切换的标准偏差。我意识到 Windows 不是实时操作系统，也不能保证，但 Windows 调度程序是一个基于公平循环优先级的调度，并且此测试中的两个线程都处于最高优先级（唯一应该是的线程高），所以线程上不应该有任何上下文切换（从 1.58 毫秒的最大时间可以看出......我相信 windows quanta 是 15.65 毫秒？）我唯一能想到的是操作系统调用时间的变化CCR 用于在线程之间传递消息的锁定机制。

请让我知道是否有其他人测量过线程间消息传递时间，并对如何改进它有任何建议。

这是我测试的源代码：

我在 Microsoft CCR 论坛上阅读了一篇关于减少调用 Port.Post() 开销的帖子 [参考：CCR 中的 PortElement 实例化]，我想知道是否有类似的方法可以将端口绑定到其接收器为了在交错仲裁器中使用 OptimizedSingleReissueReceiver 模式下的端口？

我已经实现了以下代码，在 Interleave 上使用此 PortMode：

起初，它似乎没问题，但是我仍然不时收到 NullReferenceException （此异常表明端口尚未绑定到接收器）。

有谁知道在交错中使用 PortMode.OptimizedSingleReissueReceiver 的另一种方法？

希望你们中的一些人可以就这一点给出一些指示。

我生成代码，我必须调用远程资源，如 web 服务或数据库。

考虑这段代码

对于 50 个孩子，它将调用 50 次服务，占用 50 倍的开销。在我现实生活中的例子中，这很容易是一百万个调用，使整个事情变得爬行。

我想做的是以某种对调用线程/任务透明的方式批处理这些调用。因此，它不是直接调用服务，而是调用一些对这些调用进行批处理的中央队列（“火车站”）。

因此，当它这样做时，调用任务会阻塞。然后队列等待 X 调用累积，然后使用请求列表对远程服务进行 1 次调用。

当结果出现时，该队列将返回值返回给正确的任务并解除阻塞。对于调用线程，所有这些都保持隐藏，看起来就像另一个函数调用。

这可以做到吗？TPL 中是否有原语可以让我这样做？

它有点像 CCR 的气味，有很多事情在同时进行，等待其他事情完成。

我当然可以重写此代码以在 Parent 类上创建请求列表，然后调用该服务。问题是我的真正问题是生成了所有这些代码。因此，我必须“深入了解” Child.RemoteCall 的实现，这使得这一切变得比现在复杂得多。此外，孩子可能是远程对象等的代理。如果可行的话，这将非常困难，我宁愿隔离这种复杂性。

希望这对某人有意义，如果不让我知道，我会详细说明。