c#的
var t1 = send1Async();
var t2 = send2Async();
var t3 = send3Async();
_ =Task.WhenAny(t1, t2, t3);

函数原型
async Task send1Async()；

如此简单，为什么会觉得这个是问题？
【 在 hgoldfish 的大作中提到: 】
: python 有协程锁啊。go 的话有 channel 可以通信。总之协程之间也是需要协调的。
: 举个例子：
: 同时向三个后端服务器发送请求，任何一条成功则继续。
: ...................
--
修改:leadu FROM 123.116.196.*
FROM 123.116.196.*

常见同步原语都可以用于协程，另外协程也有本身的锁，用于释放执行当前协程的线程，提升吞吐。不过不少语言的二代协程属于刚刚萌芽状态，没有就是了

https://github.com/microsoft/vs-threading
https://github.com/StephenCleary/AsyncEx
【 在 ylh1969 的大作中提到: 】
: 我知道。你说的很对。
: 不管哪个平台，都需要自己包个事件。
: 锁的问题，比较复杂，哪个平台提供了协程锁？
: ...................
--
FROM 123.116.196.*

是啊。本来就很简单。最简单的实现只要不到三百行的代码。

但这就是同步模型啊。

【 在 leadu (leadu) 的大作中提到: 】
: c#的
: var t1 = send1Async();
: var t2 = send2Async();
: ...................
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*

只会c的貌似拿不了很高的工资吧。
【 在 tianzong 的大作中提到: 】
: 我也只会c啊
--
FROM 183.221.18.*

以前有个比较有名的actor的叫libtheron，不过作者已经不维护了。现在大家都用caf。
我以前实现过一个actor模型，只用uint64_t做邮箱地址。actor模型的优点是结构简单，完全不会出现死锁。
一个人业余单打独斗，能轻松搞定10W+行的project。

我感觉得到的缺点：
1.硬性把逻辑拆分配成消息模式。
2.actor模型不太符合类的继承模式。
3.消息模式下连续逻辑实现有困难，不过coroutine刚好可以克服。



【 在 hgoldfish 的大作中提到: 】
: 这种方案的话，协程锁的开销比较大。我之前也考虑过这种方案。你前面也说过，可能不太适合有复杂交互的。
: go 语言其实也是你这种方案，所以需要引入 channel 这个东东。使用所谓的 CSP 模型，和所谓的 ACTOR 方案差不多，而不是开销巨大的锁模型。
: 总之我觉得一定要有协程间同步，不然不够用。
: ...................
--
FROM 158.140.1.*