ParallelFor 中包含的 WF 序列中的所有活动都应该是 AsyncCodeActivity 吗？
AI 有一个 WF 4 应用程序，其中包含一个序列工作流，该工作流具有一个包含具有三个连续活动的序列的 ParallelFor。 第一个活动是计算密集型的（它生成证书签名请求），第二个是 IO 密集型的（它发送电子邮件），第三个任务也是 IO 密集型的（它更新数据库）。
我最初将这些全部开发为 CodeActivities，并且发现它们需要成为 AsyncCodeActivities 才能真正在多线程模式下运行。因此，我将第一个计算绑定活动修改为 AsyncCodeActivity，我可以看到它正在多线程执行。 （至少我可以在我的开发机器上观察到更高的处理器利用率，这让我相信它现在正在运行多线程）
但是后续任务仍然是非异步代码活动。我的问题如下：
我是否应该将第二个和第三个活动也转换为异步（我怀疑会是这种情况）？
如果不是，当第一个是 AsyncCodeActivitiy 而第二个和第三个不是时，ParallelFor 中的处理实际上是如何执行的？
AI have a WF 4 application which contains a sequence workflow that has a ParallelFor containing a Sequence with three sequential activites.
The first of these activities is compute-bound (it generate Certificate Signing Requests), the second is IO bound (it sends emails) and the third task is also IO bound (it updates database).
I initially developed these all as CodeActivities and the saw that they need to be AsyncCodeActivities to truly run in multi-threaded mode. So I have modified the first compute-bound activity as an AsyncCodeActivity and I can see it is being executed multi-threaded. (At least I can observe much higher processor utilisation on my Dev machine which leads me t believe it is now running multi-threaded)
However the subsequent tasks remain as non-Async CodeActivities. My questions are as follows:
Should I convert the 2nd and 3rd activities to Async as well (I suspect this will be the case)?
If not, how is the processing actually executed within the ParallelFor when the first is AsyncCodeActivitiy and the 2nd and 3rd are not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于所有儿童活动都是并行的，因此它们被安排在同一时间。这意味着放入队列中，调度程序一次只会执行一个。对于异步活动，这意味着开始部分已被调度，并且它可以生成其他线程，而结束部分在收到完成信号时被调度，并在调度程序开始执行时真正执行。
实际上，这意味着对于在服务器上执行的具有大量其他工作的工作流，异步活动最好用于异步 IO，例如网络或数据库 IO。在服务器上，向已经繁忙的系统添加多个 CPU 线程甚至会减慢速度。如果工作流在客户端上执行，则异步 IO 和 CPU 工作都有意义。
With all child activities in a parallel they are scheduled at the same time. This means put in a queue and the scheduler will only execute a single at the time. With async activities this means that the start is scheduled and it can spawn other threads and the end part is scheduled when it is signaled as done and really executes when the scheduler get around to it.
In practice this means that for workflows that execute on a server with plenty of other work the async activity is best used for async IO like network or database IO. On a server adding multiple CPU threads to an already busy system can even slow things down. If the workflow executes on the client both async IO and CPU work make sense.