【发布时间】:2023-04-15 17:34:01
【问题描述】:
根据这个最新的 C++ TS:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4628.pdf,基于对 C# async/await 语言支持的理解,我想知道 C++ 协程的“执行上下文”(从 C# 借用的术语)是什么?
我在 Visual C++ 2017 RC 中的简单测试代码显示,协程似乎总是在线程池线程上执行,应用程序开发人员几乎无法控制协程可以在哪个线程上下文上执行 - 例如应用程序是否可以强制所有协程(使用编译器生成的状态机代码)仅在主线程上执行, 不涉及任何线程池线程?
在 C# 中,SynchronizationContext 是一种指定“上下文”的方法,其中所有协程“半”(编译器生成的状态机代码)将被发布和执行,如本文所示:https://blogs.msdn.microsoft.com/pfxteam/2012/01/20/await-synchronizationcontext-and-console-apps/,而当前协程Visual C++ 2017 RC 中的实现似乎总是依赖于并发运行时,它默认在线程池线程上执行生成的状态机代码。用户应用程序是否可以使用类似的同步上下文概念将协程执行绑定到特定线程?
此外,在 Visual C++ 2017 RC 中实现的协程的当前默认“调度程序”行为是什么?即 1) 如何准确指定等待条件? 2)当等待条件满足时,谁调用挂起的协程的“下半部分”?
我对 C# 中的任务调度的(天真的)猜测是,C# 纯粹通过任务继续来“实现”等待条件 - 等待条件由 TaskCompletionSource 拥有的任务合成,任何需要等待的代码逻辑都将被链接为它的延续,所以如果满足等待条件,例如如果从低级网络处理程序接收到完整消息,它会执行 TaskCompletionSource.SetValue,它将底层任务转换为完成状态,有效地允许链接的继续逻辑开始执行(将任务从以前创建的状态) - 在 C++ 协程中,我推测 std::future 和 std::promise 将用作类似的机制(std::future 是任务,而 std::promise 是 TaskCompletionSource,以及用法也惊人地相似!)- C++ 协程调度程序(如果有的话)是否依赖某种类似的机制来执行行为?
[编辑]:经过进一步研究,我能够编写一个非常简单但非常强大的抽象,称为 awaitable,它支持单线程和协作多任务处理,并具有一个简单的基于 thread_local 的调度程序,可以在线程上执行协程root 协程启动。代码可以从这个 github repo 中找到:https://github.com/llint/Awaitable
Awaitable 是可组合的,它在嵌套级别保持正确的调用顺序,并且它具有原始屈服、定时等待和从其他地方设置就绪的特点,并且可以从中派生出非常复杂的使用模式(例如无限循环协程仅在某些事件发生时才被唤醒),编程模型紧密遵循基于 C# 任务的异步/等待模式。请随时提供您的反馈。
【问题讨论】:
-
我认为您的问题同样适用于将调用future::then 的线程/上下文,即未定义¯_(ツ)_/¯
-
感谢 cmets。然而,至于“谁”调用延续,我推测应该有一些建议的标准措辞或工具来支持自定义单线程协程调度程序的实现 - 例如。如果一切都将在主线程上执行,则应该有一个可以在主线程上调用的主调度程序循环(或滴答声),所有计划的“任务半”都将在主线程上执行 - 或“主”线程可以是我针对更不可控的线程池线程选择的任何线程。
-
它就在那里,甚至还有the same name。只是更难找到,concurt 没有很好的记录。您可能没有在同一线程上看到继续恢复,因为您使用的是默认调度程序。支持应用程序模型的类库的工作是正确的,线程必须合作并解决生产者-消费者问题(也就是有一个调度程序循环)。当您以 WinRT(又名 UWP)项目为目标时,您会得到一个。
标签: c++ multithreading async-await coroutine c++-coroutine