多线程如何在Cadence/Temporal工作流中工作？
在Cadence/Temoral工作流编程中：
-
< li >不允许使用本机线程库。例如，在Java中，线程必须通过< code>Async.procedure或< code>Async.function创建，而在Golang中，线程必须通过< code>workflow创建。去吧。那为什么呢？ < li >有没有类似使用本机线程的竞争条件？例如，为了线程安全，应该使用< code>Hashtable或< code>ConcurrentHashMap而不是< code>HashMap？
共有1个答案
工作流执行必须是确定性的。这是历史回放重建线程状态所必需的。为了具有确定性，Cadence/Temporal以合作方式控制线程调度（而不是像大多数操作系统那样抢占）：
-
< li >在任何时间点只能运行一个工作流线程 < li >只有当当前正在执行的工作流线程被别的东西阻塞时，它才会让步，让下一个工作流线程去运行。 < li >“下一个工作流程线程”的顺序是确定的。
因此:
- 工作流代码中永远不允许本机线程库，因为Cadence/Temporal将失去对决定论的控制
- 由于协作多线程，我们通常遇到的赛车情况永远不会发生。
HashMap在工作流代码中使用是安全的。
节奏/时间 SDK 具有确定性运行器来操作线程执行。例如 Java SDK、高浪 SDK。此确定性运行程序将决定以正确的顺序运行哪个工作流线程，并且一次运行一个工作流线程。对于每个决策任务，它将循环执行，直到“所有线程都被阻塞” - 运行全部阻止/执行全部阻止。
异步过程/异步函数/工作流。Go 将创建一个新线程并添加到确定性运行器中的列表中，以便控制执行。
因为任何时候只能执行一个线程，所以我们在常规代码中遇到的大多数竞争条件都不会发生。
但这并不意味着完全没有竞速条件，在某些情况下，还是会有条件造成一些死锁。
换句话说，合作并不意味着没有竞争条件或死锁。这只是意味着死锁情况要少得多。并且没有像抢先线程调度那样导致脏读的竞争条件。
如果threadA抓取lockA并等待一个活动，那么它会屈服于threadB，然后threadB抓取lock B并等待一项活动；
活动结束后，线程 A 将在释放锁 A 之前尝试获取锁 B，线程 B 将在释放锁 A 之前尝试获取锁 A;
现在，当活动完成时，它们将陷入死锁。
https://community . temporal . io/t/how-do-workflow-thread-synchron ization-work/504
-
我计划将 Cadence 或临时工作流用于架构，但我们计划在决定工作流时为用户提供很大的权力。在他们的用例中，节奏和时间都提到他们的SDK支持自定义DSL，但我看不到该功能。你能帮帮我吗？
-
将是什么 线程不足，无法执行工作流。如果此消息始终显示，请选择WorkerOptions。应减小maxConcurrentWorklfowExecutionSize或WorkerOptions。maxWorkflowThreads增加。 处于阻塞状态的工作流在内存中保持活动状态？？处于等待状态的工作流是否持续检查条件？？更多的 -
-
为用户可视化节奏工作流的最佳方式是什么？ 我想在一个高层次的视图中向用户展示工作流的不同步骤（类似于大多数食品配送应用程序的功能：下单- 我对向用户展示实际执行的节奏活动不感兴趣，因为我不希望他们看到我的工作流程的详细信息，我只想可视化他们感兴趣的某种高级阶段。 一种方法是保留工作流的高级描述，并在工作流代码本身内部进行状态转换（在启动活动 X 时将阶段 Y 标记为已启动等）。但是，我试图将这个问
-
我正在探索Cadence，有一个关于故障恢复的问题。我知道工作流是容错的（工作流历史被维护），以防工作流工作人员失败。我找不到活动工作人员的相同保证。例如：假设一个活动对服务A进行了RPC调用，这改变了一些远程对象状态；现在，让我们假设调用成功了，但活动工作人员在通知Cadence服务之前丢失了。在这种情况下，Cadence会在一个新工作人员上再次安排活动吗？ 我知道如果服务A是幂等的，上述可能不
-
在执行任务时，如果出现故障，希望定义配置以在一定间隔后重试并从失败的任务中恢复。是否可以实现恢复选项？
-
当使用像文档建议的那样的信号时： 我可能会遇到以下问题: 我想保证一次处理一个FIFO 我想处理signalWithStart的“赛车状态”，其中信号方法调用得太早 我想安全地重置工作流。重置后，可以在历史早期重新应用信号 我想确保工作流不会在信号处理之前提前完成