epoll 边缘触发模式的问题

wishel

哦..这个可能跟应用模式有关系了..我在一般是在epoll 的线程来读取数据..然后交给数据处理线程来解析. 而不是只是标记一下这个fd可读..然后由其他线程来读取数据. 我觉得这样不可取..因为还得设置一个通知数据读取线程什么时候可读了的通知机制(或者你一直循环判断是否可读.但更CPU会100%)..这不是多此一举吗?

多线程不可取？通知机制不可取？那操作系统干嘛这么辛苦提供多线程开发模式，还搞出那么多复杂难用的同步机制，不都是多次一举么？
为什么要循环判断？线程同步机制是来干什么的？条件变量不可以用么？

这个当然是不会丢的..正因为close事件是没有数据的. 但又是一个可读事件. 才会导致丢失close 事件. (这是在recv返回长度小于请求长度后就停止recv的情况下. 而非遇到EAGAIN)

你还是没理解什么叫可读事件。et只有在状态变化才认为触发事件。
所以et模式，不能说close是可读事件，只有原来不可读，再发close通知，et才会触发。原来可读，你发close还是继续可读，没有任何事件发生。

wishel

epoll只是一个通知机制，不是通知+处理。
处理的部分是你自己做的，收到通知完全可以不处理，也不一定非要立即处理或者全部处理，想怎么样就怎么样。
epoll只保证它按照它定义的语义正确通知了你注册的fd事件。

cookis

多线程不可取？通知机制不可取？那操作系统干嘛这么辛苦提供多线程开发模式，还搞出那么多复杂难用的同步机制，不都是多次一举么？
为什么要循环判断？线程同步机制是来干什么的？条件变量不可以用么？

oh.. 别激动.. 我只是举一些例子..

你的想法倒是我没想到的. 也是一种提高并发的模式. 只让epoll负责监测, 开一个读线程来负责读取可读的fds.

wishel

原帖由 cookis 于 2008-11-10 15:49 发表


oh.. 别激动.. 我只是举一些例子..

你的想法倒是我没想到的. 也是一种提高并发的模式. 只让epoll负责监测, 开一个读线程来负责读取可读的fds.

不是激动，口气重点，未必出自恶意，呵呵

wishel

还记得L/F线程池么
epoll+线程池，可以模拟AIO

windos下的iocp的内核实现，也是类似epoll et+线程池。iocp的语义和epoll et一样。

cookis

我刚刚实现了一个基于epoll 的proactor. 但思路跟你的不一样.
http://code.google.com/p/netdkit/

我考虑过 L/F 模型.
思路(epoll + et):
1. Leader  blcking in epoll_wait
2. Followers blocking in synchronism
3. Leader get some active events. and release synchronism
3.1 Leader process these fds .
4 Promote one follower to Leader and blocking in epoll_wait.

但我做了一个实验. 如果 step-3 休息一下..没有recv. 这时候client又发数据过来(epoll 可能当做是新的事件). step-4马上会被唤醒.这时候一个fd会被两个线程操作.

当然这是我自己的实现方式.

但我觉得只要是用线程池.不管什么模式.可能都会存在这个问题.

wishel

原帖由 cookis 于 2008-11-10 17:14 发表
我刚刚实现了一个基于epoll 的proactor. 但思路跟你的不一样.
http://code.google.com/p/netdkit/

我考虑过 L/F 模型.
思路(epoll + et):
1. Leader  blcking in epoll_wait
2. Followers blocking in ...

不要用L/F线程池，它不适合这里，普通的线程池足够了
用half sync/half async
中间用一个线程安全队列做通信

[ 本帖最后由 wishel 于 2008-11-10 17:50 编辑 ]

cookis

不要用L/F线程池，它不适合这里
用half sync/half async
中间用一个线程安全队列做通信

那在你的这个模型中. recv的动作由谁来做呢?

在我的脑子里.你的意思应该是 :
Thread 1 :  epoll_wait + recv
                    |
                   \ /
MessageQueue: synchronism layout
                    |
                   \ /
Thread 2-N: data proccess layout.

如果你的想法和我的一样.. 那就跟IOCP 的模式不一样了.

[ 本帖最后由 cookis 于 2008-11-10 17:55 编辑 ]

wishel

就是说，epoll et把它的event通知塞到这个中间队列里，然后通知线程池的线程去取event通知，取走event通知的线程后面怎么处理是它自己的事情了。各线程是平等的，没有L和F之分，它们唯一要做的就是在取通知的时候注意同步互斥，但是一般这一功能已经由队列提供了（线程安全队列）。
说的太详细了很累，可以去看看half sync/half async模式就明白了。

wishel

原帖由 cookis 于 2008-11-10 17:54 发表


那在你的这个模型中. recv的动作由谁来做呢?

在我的脑子里.你的意思应该是 :
Thread 1 :  epoll_wait + recv
                    |
                   \ /
MessageQueue: synchronism layout
  ...

Thread 1没有recv，你怎么老把通知和处理混在一起？前面说了，通知和处理是分离的

[ 本帖最后由 wishel 于 2008-11-10 18:04 编辑 ]