从c++20的角度来说不存在“协程恢复线程不确定”的问题
这种情况出现的原因是在suspend以后显式地跨线程转移了协程的handle
这是技术设计上的选择，作为开发人员必然是非常清楚的
代码上也会有对应的新建线程，或者将任务加入线程池的操作
如果出现了tls的使用问题，那应该是开发人员对于协程跨线程的特点不了解

【 在 allegro (静水流深) 的大作中提到: 】
: 标  题: Re: 终于想明白协程了。
: 发信站: 水木社区 (Tue Sep 22 02:04:03 2020), 站内
:
: 这个C++20标准下的协程恢复线程不确定。
: 如果协程上下文都refer了某个tls，那么await前后看到的tls实际上可能是不同的变量。
: 虽然名字相同，代码就隔了一个await，但执行起来千差万别，这对用户来说是真·天坑。
:
: 而且协程可以挂起后在await_suspend()中让另一个线程立刻启动协程，使得当前this可能被立即销毁。
: 这对库的编写者也是大坑，不过普通用户不用关切这个。
:
: 看了这么些文档，我对那个cppcoro的event设计比较喜欢
: 无锁无风险，算是赏心悦目。比condition_variable好用多了。
:
: 【 在 z16166 的大作中提到: 】
: : 在加锁上，感觉多线程执行协程可能是个噩梦？
: : 如果A1，A2，...，An这些协程都可能在t1，t2，...，tn这些线程上执行，那么访问共享资源时直接无脑全部加锁就行，
: : 怕的就是一组协程G1在一个线程t1上执行，而另外一组协程G2在另外一个不同的线程t2上执行，G1和G2这两个协程组之间访问共享资源时需要加锁，协程组内的资源不需要加锁。
: : ...................
:
: --
: ※ 修改:·allegro 于 Sep 22 04:26:26 2020 修改本文·[FROM: 158.140.1.*]
: ※ 来源:·水木社区 http://www.newsmth.net·[FROM: 158.140.1.*]
--
修改:allegro FROM 158.140.1.*
FROM 111.200.53.*