z**********3
发帖数: 11979 | 1 【 以下文字转载自 Joke 讨论区 】
发信人: xiaopo (小坡), 信区: Joke
标 题: 我是一个线程
发信站: BBS 未名空间站 (Fri Apr 1 15:10:41 2016, 美东)
zt
我是一个线程 2016-03-30 IBM刘欣 程序猿
我是一个线程， 我一出生就被编了个号： 0x3704, 然后被领到一个昏暗的屋子里，
这里我发现了很多和我一模一样的同伴。
我身边的同伴0x6900 待的时间比较长， 他带着沧桑的口气对我说：
我们线程的宿命就是处理包裹。 把包裹处理完以后还得马上回到这里，否则可能永远
回不来了。
我一脸懵懂，包裹，什么包裹？
”不要着急，马上你就会明白了， 我们这里是不养闲人的。“
果然，没多久，屋子的门开了， 一个面貌凶恶的家伙吼道：
＂0x3704 ,出来！＂
我一出来就被塞了一个沉甸甸的包裹，上面还有附带着一个写满了操作步骤的纸。
＂快去，把这个包裹处理了。＂
＂去哪儿处理＂
＂跟着指示走， 先到就绪车间＂
果然，地上有指示箭头，跟着它来到了一间明亮的大屋子，这里已经有不少线程了，
大家都很紧张，好像时刻准备着往前冲。
我刚一进来，就听见广播说：“0x3704, 进入车间”
我赶紧往前走， 身后很多人议论说：
”他太幸运了， 刚进入就绪状态就能运行“
”是不是有关系？“
”不是，你看人家的优先级多高啊， 唉“
前边就是车间， 这里简直是太美了， 怪不得老线程总是唠叨着说：要是能一直待在这
里就好了。
这里空间大，视野好，空气清新，鸟语花香，还有很多从来没见过的人，像服务员一样
等着为我服务。
他们也都有编号， 更重要的是每个人还有个标签，上面写着：硬盘，数据库，内存，
网卡．．．
我现在理解不了，看看操作步骤吧：
第一步：从包裹中取出参数
打开包裹， 里边有个HttpRequest 对象, 可以取到 userName, password两个参数
第二步：执行登录操作
奥，原来是有人要登录啊，我把userName/password 交给 数据库服务员，他拿着数据
， 慢腾腾的走了。
他怎么这么慢？ 不过我是不是正好可以在车间里多待一会儿? 反正也没法执行第三
步。
就在这时，车间里的广播响了：
"0x3704, 我是CPU , 记住你正在执行的步骤， 马上带包裹离开"
我慢腾腾的开始收拾
”快点， 别的线程马上就要进来了“
离开这个车间， 又来到一个大屋子，这里很多线程慢腾腾的在喝茶，打牌。
”哥们，你们没事干了？“
”你新来的把， 你不知道我在等数据库服务员给我数据啊！ ，据说他们比我们慢好几
十万倍， 在这里好好歇吧“
”啊？ 这么慢？ 我这里有人在登录系统， 能等这么长时间吗"
”放心，你没听说过人间一天， CPU一年吗， 我们这里是用纳秒，毫秒计时的， 人间
等待一秒，相当于我们好几天呢， 来的及“
干脆睡一会吧 ， 不知道过了多久 ，大喇叭又开始广播了：
"0x3704， 你的数据来了，快去执行”
我转身就往CPU车间跑，发现这里的们只出不进！
后面传来阵阵哄笑声：
”果然是新人， 不知道还得去就绪车间等“
于是赶紧到就绪车间， 这次没有那么好运了， 等了好久才被再次叫进CPU车间。
在等待的时候， 我听见有人小声议论：
”听说了吗，最近有个线程被kill掉了“
”为啥啊？“
”这家伙赖在ＣＰＵ车间不走， 把CPU利用率一直搞成100%，后来就被kill掉了“
”Kill掉以后弄哪儿去了“
”可能被垃圾回收了吧“
我心里打了个寒噤 ， 赶紧接着处理， 收下的动作块多了，第二步登录成功了
第三步：构建登录成功后的主页
这一步有点费时间， 因为有很多HTML需要处理， 不知道代码谁写的，处理起来很烦人。
我正在紧张的制作html呢， CPU有开始叫了：
"0x3704, 我是CPU , 记住你正在执行的步骤， 马上带包裹离开"
”为啥啊“
”每个线程只能在CPU上运行一段时间，到了时间就得让别人用了， 你去就绪车间待着
， 等着叫你吧“
就这样， 我一直在就绪-运行 这两个状态，不知道轮转了多少次， 终于安装步骤清单
把工作做完了。
最后顺利的把包含html的包裹发了回去。
至于登录以后干什么事儿 ， 我就不管了。
马上就要回到我那昏暗的房间了， 真有点舍不得这里。
不过相对于有些线程， 我还是幸运的， 他们运行完以后就彻底的销毁了，而我还活着
！
回到了小黑屋， 老线程0x6900 问：
”怎么样？第一天有什么感觉？“
”我们的世界规则很复杂 ， 首先你不知道什么时候会被挑中执行; 第二 ，在执行的
过程中随时可能被打断，让出CPU车间;
第三，一旦出现硬盘，数据库这样耗时的操作也得让出CPU,去等待; 第四，就是数
据来了，你也不一定马上执行，还得等着CPU挑选“
”小伙子理解的不错啊“
”我不明白为什么很多线程都执行完就死了， 为什么咱们还活着？“
”你还不知道， 长生不老是我们的特权， 我们这里有个正式的名称，叫做 线程池！“
平淡的日子就这么一天天过去， 作为一个线程， 我每天的生活都是取包裹，处理包裹
，然后回到我们昏暗的家：线程池。
有一天我回来的时候， 听到有个兄弟说， 今天要好好休息下，明天就是最疯狂的一天
。
我看了一眼日历，明天是 11月11号 。
果然，零点刚过，不知道那些人类怎么了， 疯狂的投递包裹， 为了应付蜂拥而至的海
量包裹， 线程池里没有一个人能闲下来，全部出去处理包裹，CPU车间利用率超高，硬
盘在嗡嗡转， 网卡疯狂的闪， 即便如此， 还是处理不完，堆积如山。
我们也没有办法，实在是太多太多了， 这些包裹中大部分都是浏览页面，下订单，买
，买，买。
不知道过了多久， 包裹山终于慢慢的消失了。
终于能够喘口气， 我想我永远都不会忘记这一天。
通过这个事件，我明白了我所处的世界：这是一个电子商务的网站！
我每天的工作就是处理用户的登录，浏览， 购物车，下单，付款。
我问线程池的元老0x6900 ： " 我们要工作到什么时候？"
" 要一直等到系统重启的那一刻"， 0x6900 说
" 那你经历过系统重启吗？"
" 怎么可能？ , 系统重启就是我们的死亡时刻， 也就是世界末日，一旦重启， 整个
线程池全部销毁，时间和空间全部消失，一切从头再来”
" 那什么时候会重启？"
" 这就不好说了,好好享受眼前的生活吧....."
其实生活丰富多彩， 我最喜欢的包裹是上传图片，由于网络慢，所以能在就绪车间，
CPU车间待很长很长时间，可以认识很多好玩的线程。
比如说上次认识了memecached 线程，他给我说通过他缓存了很多的用户数据， 还是分
布式的！ 很多机器上都有！
我说怪不得后来的登录操作快了那么多， 原来是不再从数据库取数据了你那里就有啊
， 哎对了你是分布式的你去过别的机器没有？
他说怎么可能我每次也只能通过网络往那个机器发送一个GET, PUT命令才存取数据而已
， 别的一概不知。
再比如说上次在等待的时候遇到了数据库连接的线程， 我才知道它他那里也是一个连
接池， 和我们线程池几乎一模一样。
他说有些包裹太变态了，竟然查看一年的订单数据， 简直把我累死了。
我说拉倒吧你， 你那是纯数据， 你把数据传给我以后，我还得组装成HTML, 工作量
不知道比你大多少倍。
他说一定你要和memecached搞好关系，直接从他那儿拿数据，尽量少直接调用数据库，
我们JDBC connection也能活的轻松点。
我说好啊好啊， 关键是你得提前把数据搞到缓存啊， 要不然我先问一遍缓存， 没有
数据， 我这不还得找你吗？
生活就是这样， 如果你自己不找点乐子，还有什么意思？
有一天我遇到一个可怕的事情， 差一点死在外边，回不了线程池了......
其实这次遇险我应该能够预想到才对， 太大意了。
前几天我处理过一些从http 发来的存款和取款的包裹， 老线程0x6900 特意嘱咐我：
"处理这些包裹的时候要特别小心， 你得一定要先获得一把锁， 在对账户存款或者取
款的时候一定要把账户给锁住， 要不然别的线程就会在你等待的时候趁虚而入，搞破
坏， 我年轻那会儿很毛糙，就捅了篓子"
为了“恐吓”我， 好心的0x6900还给了我两个表格：
1、没有加锁的情况
2、加锁的情况
我看的胆颤心惊， 原来不加锁会带来这么严重的事故。
从此以后看到存款，取款的包裹就倍加小心， 还好，没有出过事故。
今天我收到的一个包裹是转账， 从某著名演员的账号给某著名导演赚钱， 具体是谁我
就不透漏了， 数额可真是不小
我按照老线程的吩咐， 肯定要加锁啊， 先对著名演员账号加锁， 在对著名导演账号
加锁。
可我万万没想到的是， 还有一个线程，对，就是0x7954, 竟然同时在从这个导演到往
这个演员转账。
于是乎，就出现了这么个情况：
刚开始我还不知道什么情况， 一直坐在等待车间傻等， 可是等的时间太长了， 长达
几十秒 ！ 我可从来没有经历过这样的事件。
这时候我就看到了线程0x7954 , 他悠闲的坐在那里喝咖啡， 我和他聊了起来：
“哥们， 我看你已经喝了8杯咖啡了， 怎么还不去干活？”
“你不喝了9杯茶了吗？” 0x7954 回敬到。
“我在等一个锁， 不知道哪个孙子一直不释放”
“我也在等锁啊，我要是知道哪个孙子不释放锁我非揍死他不可 ” 0x7954 毫不示弱。
我偷偷的看了一眼， 这家伙怀里不就抱着我正在等的 某导演的锁嘛？
很明显， 0x7954 也发现了我正抱着他正在等待的锁。
很快我们两个就吵了起来， 互不相让：
"把你的锁先给我， 让我先做完"
"不行， 从来都是做完工作才释放锁， 现在绝对不能给你"
从争吵到打起来， 就那么几秒钟的事儿。
更重要的是， 我们俩不仅仅持有这个著名导演和演员的锁， 还有很多其他的锁， 导
致等待的线程越来越多， 围观的人们把屋子都挤满了。
最后事情真的闹大了， 我从来没见过终极大boss "操作系统" 也来了。
大Boss毕竟是见多识广， 他看了一眼， 哼了一声 ， 很不屑的说：
"又出现死锁了"
"你们俩要Kill掉一个， 来吧， 过来抽签 "
这一下子把我给吓尿了， 这么严重啊！
我战战兢兢的抽了签，打开一看， 是个"活"字。
唉，小命终于保住了。
可怜的0x7954 被迫交出了所有的资源以后， 很不幸的被kill掉， 消失了。
我拿到了导演的锁， 可以开始干活了。
大Boss操作系统如一阵风似的消失了， 身后只传来他的声音：
记住， 我们这里导演>演员， 无论认识情况都要先获得导演的锁
由于不仅仅是只有导演和演员， 还有很多其他人， Boss留下了一个表格， 里边是个
算法， 用来计算资源的大小， 计算出来以后,永远按照从大到小的方式来获得锁：
我回到线程池， 大家都知道了我的历险， 围着我问个不停。
凶神恶煞的线程调度员把大Boss的算法贴到了墙上。
每天早上， 我们都得像无节操的房屋中介， 美容美发店的服务员一样， 站在门口，
像被耍猴一样大声背诵：
"多个资源加锁要牢记， 一定要按Boss的算法比大小， 然后从最大的开始加锁"
--------------------------------------------------------
又过了很多天， 我和其他线程们发现了一个奇怪的事情：包裹的处理越来越简单
不管任何包裹，不管是登录， 浏览，存钱..... 处理的步骤都是一样的, 返回一个固
定的html页面
有一次我偷偷的看了一眼， 上面写着：
"本系统将于今晚 00:00 至4:00 进行维护升级， 给你带来的不便我们深感抱歉"
我去告诉了老线程0x6904, 他叹了一口气说：
"唉， 我们的生命也到头了， 看来马上就要重启系统， 我们就要消失了， 再见吧兄
弟。"
系统重启的那一刻终于到来了。
我看到屋子里的东西一个个的不见了， 等待车间，就绪车间，甚至CPU车间都慢慢的消
失了。
我身边的线程兄弟也越来越少， 最后只剩我自己了。
我在空旷的原野上大喊： 还有人吗？
无人应答。
我们这一代线程池完成了使命。
下一代线程池将很快重生。
（完） |
w***g
发帖数: 5958 | 2 老魏的polling线程表示很爽。然后就被GPU上的SIMD线程鄙视了。
投胎绝对是一门学问。
，
【在 z**********3 的大作中提到】
: 【 以下文字转载自 Joke 讨论区 】
: 发信人: xiaopo (小坡), 信区: Joke
: 标 题: 我是一个线程
: 发信站: BBS 未名空间站 (Fri Apr 1 15:10:41 2016, 美东)
: zt
: 我是一个线程 2016-03-30 IBM刘欣 程序猿
: 我是一个线程， 我一出生就被编了个号： 0x3704, 然后被领到一个昏暗的屋子里，
: 这里我发现了很多和我一模一样的同伴。
: 我身边的同伴0x6900 待的时间比较长， 他带着沧桑的口气对我说：
: 我们线程的宿命就是处理包裹。 把包裹处理完以后还得马上回到这里，否则可能永远
|
s***o
发帖数: 2191 | 3 wdong有没有研究过java fiber/quasar?
http://docs.paralleluniverse.co/quasar/
【在 w***g 的大作中提到】
: 老魏的polling线程表示很爽。然后就被GPU上的SIMD线程鄙视了。
: 投胎绝对是一门学问。
:
: ，
|
w***g
发帖数: 5958 | 4 这个我没有研究过。我做的东西OS threads足够用了。
我不知道fiber/go-routine这些对实际系统帮助有多大。
一般来说用thread的系统和用fiber的系统本身设计上
就有很大的不同。一个系统本身用fiber写，然后换成
thread后性能下降很大，或者一个系统本身用thread
写，换成fiber后性能下降很大都有可能。
对于大部分人人，我建议OS thread就足够了。如果有
瓶颈，一方面是从I/O开销调，改进I/O pattern，上
更快的SSD，另一方面是数据库索引和查询优化。
操作系统在context switch上面的这点开销和上面两个
比都是微不足道的。如果上面这两个出了问题，改
fiber对提高性能不会有帮助。相反，因为fiber是
cooperative的，程序写得不小心可能会导致系统挂起，
而且调试起来会非常啰嗦。(OS thread可以直接
打印call stack。Go是语言支持，应该也没问题。
Quasar就不知道了。C/C++也有fiber实现，想要调试
那是不可能的。）
【在 s***o 的大作中提到】
: wdong有没有研究过java fiber/quasar?
: http://docs.paralleluniverse.co/quasar/
|
w***g
发帖数: 5958 | 5 一般fiber库会强调fiber overhead很小，可以跑几乎
无穷多个fiber线程。“无穷多个线程”其实是个伪需求。
比如处理http请求，无穷多个请求只有在一个请求新起
一个线程的情况下才会出现。正经点的需求肯定用的是
线程池，一台机器最多处理多少并行请求，开多少线程，
设计的时候都应该是定了的，超出设计请求量比如60%，
基本上就得开始起新机器做load balancing了。
我觉得在下面这种情况下可能fiber会有用。就是公司
人多，本来一个处理流程拆成１００步，之间通过
MQ连接，然后有１００个线程池并行处理。通过这种
办法，试图把软件的整合转换为服务的整合。
效果怎么样，我觉得也只有用的人自己知道。
如果公司小就几个人啥事情都要自己干的，我觉得
这种做法显然是自找麻烦。
【在 w***g 的大作中提到】
: 这个我没有研究过。我做的东西OS threads足够用了。
: 我不知道fiber/go-routine这些对实际系统帮助有多大。
: 一般来说用thread的系统和用fiber的系统本身设计上
: 就有很大的不同。一个系统本身用fiber写，然后换成
: thread后性能下降很大，或者一个系统本身用thread
: 写，换成fiber后性能下降很大都有可能。
: 对于大部分人人，我建议OS thread就足够了。如果有
: 瓶颈，一方面是从I/O开销调，改进I/O pattern，上
: 更快的SSD，另一方面是数据库索引和查询优化。
: 操作系统在context switch上面的这点开销和上面两个
|
s***o
发帖数: 2191 | 6 quasar一直没火起来，除了没有大公司在背后推手，我觉得更主要的就像你说的，没有
非要用它的合适场景。这个我就先扔一边不看了。谢谢
【在 w***g 的大作中提到】
: 一般fiber库会强调fiber overhead很小，可以跑几乎
: 无穷多个fiber线程。“无穷多个线程”其实是个伪需求。
: 比如处理http请求，无穷多个请求只有在一个请求新起
: 一个线程的情况下才会出现。正经点的需求肯定用的是
: 线程池，一台机器最多处理多少并行请求，开多少线程，
: 设计的时候都应该是定了的，超出设计请求量比如60%，
: 基本上就得开始起新机器做load balancing了。
: 我觉得在下面这种情况下可能fiber会有用。就是公司
: 人多，本来一个处理流程拆成１００步，之间通过
: MQ连接，然后有１００个线程池并行处理。通过这种
|
T********i
发帖数: 2416 | 7 其实归根结底都是一个成本问题。
现在的系统架构都设计成Service-Oriented。这是所有问题的根源。web的架构本身就
是单向通信，req/resp。过把瘾就死。这种架构下，业务逻辑就要一级级往下走。如果
业务逻辑不涉及I/O，那么对性能基本没有影响。但是不涉及I/O的是不可能的。所以才
有各种各样的奇技淫巧。
以前java/php/ruby之类的架构，都是一个thread对应一个请求，顶多用thread pool限
制一下。所以都是thread大多数时候blocking for I/O。这种情况，不论是否用thread
pool，都会有各种各样的性能损失。
node.js之类的，利用层层回调解决I/O multiplexing的问题。即使是基于性能很差的
js，也能超多java之类的。最大的问题是，对于老应用需要重写。
fiber/go-routine其实都是co-routine。如果做得好，其实legacy代码需要的改动会很
小。这是很大的优势。go是新语言，不存在代码重写的问题。go对应于node.js也就是
说起话来能流畅一点，而且runtime性能更好。所以本版那些前两年鼓吹node的现在都
转go了。
其实上次你说C++将来能natively支持co-routine倒是有可能。但是所谓thread::yield
之类的是为了co-routine留接口之类就不对了，这两种yield根本差异，怎么可能混用？
至于polling和GPU SIMD，根本橘子苹果。一个针对I/O，另一个是特殊用途。再说了，
保持CPU/GPU利用率接近100%的实现者的责任，具体咋做不重要。我最近一次写SIMD还
是4年前。以后再也不想写了。
【在 w***g 的大作中提到】
: 这个我没有研究过。我做的东西OS threads足够用了。
: 我不知道fiber/go-routine这些对实际系统帮助有多大。
: 一般来说用thread的系统和用fiber的系统本身设计上
: 就有很大的不同。一个系统本身用fiber写，然后换成
: thread后性能下降很大，或者一个系统本身用thread
: 写，换成fiber后性能下降很大都有可能。
: 对于大部分人人，我建议OS thread就足够了。如果有
: 瓶颈，一方面是从I/O开销调，改进I/O pattern，上
: 更快的SSD，另一方面是数据库索引和查询优化。
: 操作系统在context switch上面的这点开销和上面两个
|
w***g
发帖数: 5958 | 8 std::thread对实现没有明确要求，理论上说可以是用户态线程也可以是操统线程。
可以是preemptive也可以是cooperative。比如说把std::thread移植回windows 3.1，
就会出现cooperative的操统线程。C++的yield是为了支持cooperative thread，
跟coroutine没有直接的关系。
coroutine是语言概念，基本上相当于(python的)"yield"关键字。thread是操作系统概
念，
基本上就是share memory space的process。虽然对于没有yield关键字的语言，
可以用类似cooperative user-space thread的方式实现。但是在编程模型上
的用法是有区别的。一个例子就是thread A上面跑了coroutine A1和A2，
thread B上跑了coroutine B1和B2。其中A1和B2在某一步用mutex进行了同步。
那么这个mutex同步的是线程A和B。Coroutine本身是没有同步概念的。
thread
【在 T********i 的大作中提到】
: 其实归根结底都是一个成本问题。
: 现在的系统架构都设计成Service-Oriented。这是所有问题的根源。web的架构本身就
: 是单向通信，req/resp。过把瘾就死。这种架构下，业务逻辑就要一级级往下走。如果
: 业务逻辑不涉及I/O，那么对性能基本没有影响。但是不涉及I/O的是不可能的。所以才
: 有各种各样的奇技淫巧。
: 以前java/php/ruby之类的架构，都是一个thread对应一个请求，顶多用thread pool限
: 制一下。所以都是thread大多数时候blocking for I/O。这种情况，不论是否用thread
: pool，都会有各种各样的性能损失。
: node.js之类的，利用层层回调解决I/O multiplexing的问题。即使是基于性能很差的
: js，也能超多java之类的。最大的问题是，对于老应用需要重写。
|
w***g
发帖数: 5958 | 9 coroutine和monitor是两个基本上被实践抛弃了的概念。python的
yield其实是标准的coroutine，但是一般讲python的资料都会把它
叫做iterator或者generator。现在还在提coroutine的，一般都是
哗众取宠混淆视听。
如何区别coroutine和thread的一个标准就是：coroutine的yield
返回后，执行权落在那一行程序是确定的，由程序的
逻辑决定。thread yield/preempt了以后，执行权落在那一行程序是
不确定的，由thread scheduler决定的。即使是cooperative thread
跑在一个CPU上，执行权落哪儿也是不确定的。
goroutine就是一种light-weighted thread，不是coroutine。
wikipedia上那篇coroutine也是概念非常混淆乱讲一通。其实只要
程序写对了，抠概念屁用没有。我书读太多脑子有点坏掉了。
【在 w***g 的大作中提到】
: std::thread对实现没有明确要求，理论上说可以是用户态线程也可以是操统线程。
: 可以是preemptive也可以是cooperative。比如说把std::thread移植回windows 3.1，
: 就会出现cooperative的操统线程。C++的yield是为了支持cooperative thread，
: 跟coroutine没有直接的关系。
: coroutine是语言概念，基本上相当于(python的)"yield"关键字。thread是操作系统概
: 念，
: 基本上就是share memory space的process。虽然对于没有yield关键字的语言，
: 可以用类似cooperative user-space thread的方式实现。但是在编程模型上
: 的用法是有区别的。一个例子就是thread A上面跑了coroutine A1和A2，
: thread B上跑了coroutine B1和B2。其中A1和B2在某一步用mutex进行了同步。
|
T********i
发帖数: 2416 | 10 coroutine和iterator根本就是两个概念。coroutine有自己的stack，yield以后也要有
context switch，iterator不一定。
基于coroutine可以有multi-task和scheduler。因此coroutine yield以后，可以直接
回到scheduler，执行权落在那一行程序是由scheduler决定，不一定是确定的。
因此coroutine和thread很像。但是就是yield的含义不一样。我不确定std::thread实
现coroutine是不是一个好主意？因为为了能够做到兼容，因为thread多任务不需要
yield也能保证响应，但是coroutine必须yield，因此为了保证兼容性长任务要插入
yield才能保证响应，但是会带来额外的负担。
goroutine这种就是coroutine，context switch只需要切换stack和register，不需要
flush cache，switch TLB，security check，这些都是微秒级别的操作。而且内置
scheduler
，还要在I/O函数外面包上wrapper才行。
串行blocking I/O的好处是说话能够连贯。所以co-routine现在又被捡回来了。
【在 w***g 的大作中提到】
: coroutine和monitor是两个基本上被实践抛弃了的概念。python的
: yield其实是标准的coroutine，但是一般讲python的资料都会把它
: 叫做iterator或者generator。现在还在提coroutine的，一般都是
: 哗众取宠混淆视听。
: 如何区别coroutine和thread的一个标准就是：coroutine的yield
: 返回后，执行权落在那一行程序是确定的，由程序的
: 逻辑决定。thread yield/preempt了以后，执行权落在那一行程序是
: 不确定的，由thread scheduler决定的。即使是cooperative thread
: 跑在一个CPU上，执行权落哪儿也是不确定的。
: goroutine就是一种light-weighted thread，不是coroutine。
|
P****9
发帖数: 177 | |
w***x
发帖数: 105 | 12 感觉coroutine在某些特殊情况下，能避免使用multi-thread。。。
有些好奇，比如coroutine的r/w queue有无标准实现？多个reader,一个writer，贴个
代码看看。。。 |
