- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
没这么简单哦。。你可以参考一下 libgo 和 cppcoro 啊。看看它们是怎么实现协程版本的 mutex, timer 等等的。
【 在 ylh0315 的大作中提到: 】
: 协程调度就是epoll呀！
: 主线程创建协程，丢进epoll。所有的线程都在epoll_wait，抓住哪个做哪个协程。协程在yield时，设置epoll，并swapcntext。epoll激活这个协程后，由一个线程进行resume。
: 整个的调度过程。
: ...................
--
FROM 183.253.146.*
每个协程配一个asio deadline timer 不过看他对他那个构架这么津津乐道的样子 估计没用过asio框架
他这点需求和吞吐量 对asio根本不是个事
【 在 hgoldfish 的大作中提到: 】
: 额～我也不知道为啥 ylh0315 一直在说栈、超时这些协程实现的东东。按说都是已经被研究得差不多的 ...
--
FROM 36.28.191.*
network processor 也好，FPGA 也好，ASIC 也好，架构里还是有 memory system，总不可能全部数据都在 register file 甚至全都在 crossbar 里吧？当然可以设计成多核之间完全并行，不共享 memory port，总线还是会有 contention 吧？
是不是因为并发的数量很小（小于几千）所以可以做一个大块的 mesh，做到整个 dataflow 完全没有 contention 而不影响 thruput？
btw，这种公司是只设计 IP，后续工作全部外包出去，还是自己设计整个 SoC，直接跟 fab 接口？
【 在 ziqin 的大作中提到: 】
: 因为你在说纳秒级别 如果kernel by pass只省了纳秒级别 那么用cpu跑交易逻辑是没有意义的 因为随便一个大一些的cache miss或者cpu 切片都比这个大
所有你看见的纳秒级的tick to trade的 都是交易逻辑直接烧在网卡芯片里的
CPU处理交易逻辑的 就算再kernel by pass 也会涉及到硬件中断 甚至就算你的网卡芯片可以by pass cpu直接写内存 你绑交易逻辑的核也需要读内存而不是读缓存 就算读缓存 只要你不是读一级缓存 在现在cpu的构架下 都涉及同步各个核之间的缓存同步
绝大部分墙街的公司 除了真正的几个用fpga的头部玩家 无非都是照猫画虎而已
--
FROM 37.136.9.*
主要是协程，在进行IO的超时，也包括在队列中等待的超时。
无论哪种超时，都可以在context数组中检测到。主线程负责这个检测。
【 在 hgoldfish 的大作中提到: 】
: 你又不是在多个线程间调度协程的超时。
: 话说，你可以参考一下操作系统的线程调度。因为你现在做的事情，已经相当于在 userland 自行实现了一份操作系统的内核线程调度了。
: 所以我有个观点是，能够实现协程调度的程序员，也必然有能力实现操作系统内核。
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
github打不开。
协程锁没有搞，暂时没有用到。
协程安全，主要就是线程锁不允许跨越IO（因为IO可能发生线程切换，函数返回就不是原来的线程了）。
【 在 hgoldfish 的大作中提到: 】
: 一般协程库要三个部分：
: 1. 基础的协程切换，一般由语言库(c++ co_await)或者操作系统(swap_context)搞定
: 2. 事件循环以及协程调度(线程内与线程间调度)
: ...................
--
FROM 221.218.61.*
就这么简单呀，线程从epoll里得到一个协程，就会一直运作下去，不需要调度，直到遇到IO不能完成，需要等待才进行yield（见84楼），协程丢进epoll队列，线程继续epoll_wait。
【 在 hgoldfish 的大作中提到: 】
: 没这么简单哦。。你可以参考一下 libgo 和 cppcoro 啊。看看它们是怎么实现协程版本的 mutex, timer 等等的。
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
接115楼。
你可能会问，如果协程运行期间一直不调度（实际上就我这个交易管理器来说，不就是个消息转发吗？没啥工作量），别的任务怎么办呀？
别的任务有别的线程。有几个核就有几个线程（也可能多几个）。
所有线程都占满了呢？那就是达到了系统处理能力的极限了呗（应该可以看到CPU100%，实际见到过85%）。等不到服务的协程就在epoll里等着呗。
一般的交易虽说也是要求响应快，也没那么紧迫，耽误就耽误点。主要是别丢失交易和保证交易的完整性。
就如12306，迟钝就迟钝点，抢不到票就抢不到，有啥了不起。
如果发现处理能力吃紧，以后增加系统配置就得了。
【 在 hgoldfish 的大作中提到: 】
: 没这么简单哦。。你可以参考一下 libgo 和 cppcoro 啊。看看它们是怎么实现协程版本的 mutex, timer 等等的。
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
说高频交易，要看是多高频
大家在抬杠过程中，总是说纳秒级，那我们就说纳秒级的tick to trade策略
交易所统计数据中，从新的tick发出，到收到下一次order flow的第一批高峰，大概是在16ns到500ns左右，这一批策略，基本上就是你说的，并发量在100(当然，对交易来说100也不小了）以内，因为基本上是一块芯片对一个合约，网卡收到交易所收到数据以后，所有的FIX解包就在网卡芯片上直接完成，然后的确是一个大的mesh，直接算出来，所有的策略参数，都是烧死在硬件里的，尽量减小动态读取的次数。这批头部玩家的主要区别其实是网线接在交易所路由器的第几个口，因为路由器背板转发事实上也是有先后的，能相差十几纳秒
【 在 philbloo 的大作中提到: 】
: network processor 也好，FPGA 也好，ASIC 也好，架构里还是有 memory system，总不可能全部数据都在 register file 甚至全都在 crossbar 里吧？当然可以设计成多核之间完全并行，不共享 memory port，总线还是会有 contention 吧？
: 是不是因为并发的数量很小（小于几千）所以可以做一个大块的 mesh，做到整个 dataflow 完全没有 contention 而不影响 thruput？
: btw，这种公司是只设计 IP，后续工作全部外包出去，还是自己设计整个 SoC，直接跟 fab 接口？
: ...................
--
FROM 183.128.163.*
感觉是GPS或者说北斗的交易，或者战场的战术数据链。你说的确实很对。这种场景还是别用协程了，不够耽误事的。
【 在 ziqin 的大作中提到: 】
: 说高频交易，要看是多高频
: 大家在抬杠过程中，总是说纳秒级，那我们就说纳秒级的tick to trade策略
: 交易所统计数据中，从新的tick发出，到收到下一次order flow的第一批高峰，大概是在16ns到500ns左右，这一批策略，基本上就是你说的，并发量在100(当然，对交易来说100也不小了）以内，因为基本上是一块芯片对一个合约，网卡收到交易所收到数据以后，所有的FIX解包就在网卡芯片上直接完成，然后的确是一个大的mesh，直接算出来，所有的策略参数，都是烧死在硬件里的，尽量减小动态读取的次数。这批头部玩家的主要区别其实是网线接在交易所路由器的第几个口，因为路由器背板转发事实上也是有先后的，能相差十几纳秒
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
不参与你们对协程的讨论，太蠢了
如果一个系统可以上通用os，windows有rio，intel抄了个半成品是dpdk，linux不会表现的比windows更好。
除非你裁剪linux内核，但都到了要裁剪内核的地步，我为啥不写点verilog直接fpga甚至asic搞定？
别一知半解的就瞎喷
【 在 ylh0315 的大作中提到: 】
: 嗯。说的都是linux。大规模交易系统，WINDOWS太不靠谱了。
--
FROM 114.246.175.*