关于并发模型的一些想法 #1212
Replies: 3 comments
-
|
服务并不是绑定在线程上的，当服务在线程间迁移，同一服务发出的消息的次序就无法得到保证。 btw, 去掉锁并非主要目的。 |
Beta Was this translation helpful? Give feedback.
-
|
这套方案也不简单, 先不说遍历N个队列的开销, 实现等待和通知的机制也很麻烦, 完善的实现也很复杂, 最终成本未必降低. |
Beta Was this translation helpful? Give feedback.
-
既然ctx绑定线程了，何不去掉服务队列，消息存线程消息队列，每个线程准备两个消息队列，‘handle on swap’, 这样也可以大大降低锁竞争 |
Beta Was this translation helpful? Give feedback.
-
云大，前几天看了您写的《skynet并发模型的一点改进思路》这篇文章，我有一些想法，希望云大指点一下。
假设有N个线程，那就生成N*N个消息队列message_queue，第0个线程只操作第一行的队列，第1个线程只操作第二行的队列......
每个ctx绑定在某个线程上，在ctx上加一个字段属于哪个线程，当要发送数据的时候，就获取当前线程ID（哪一行），目标ctx的线程ID（哪一列），用这两个ID找到相应的队列，往这队列push数据。
当分发数据的时候，只需要遍历属于当前线程的消息队列即可。比如：当前线程ID: 1，那么操作 第0行的第1列的队列，第1行的第1列的队列......
这套方案可以做到无锁操作队列，并且也保证一个服务向另一个服务发送数据的有序性。
但是当多个服务向一个服务发送数据的时候，执行的顺序就得不到保证。比如A，B服务分别向C服务发送数据，A先于B发送，可能会出现B的消息先被执行，这与原先设计相悖。
这套方案我已经写出来，用example/config.login测试，能正常运行，但我这里只是并发量小的环境，感觉无法得出正确的结果。
所以，我想请教下云大，这套方案是否可取？
Beta Was this translation helpful? Give feedback.
All reactions