Linux事件監(jiān)控機(jī)制遺漏事件問題的相關(guān)分析
目前比較通用的監(jiān)控Linux下文件系統(tǒng)變化的是Epoll+iNotify結(jié)合的機(jī)制.
Epoll有兩種機(jī)制,LevelTrigger和EdgeTrigger, 前者相當(dāng)于fast poll, 后者可以理解為對(duì)nonblocking fd的阻塞化, 這個(gè)說法嚴(yán)格來講有點(diǎn)兒業(yè)余,只是為了簡(jiǎn)單的說明問題.
對(duì)于從epoll_wait等待事件觸發(fā),然后進(jìn)行read.這里做下說明,在讀事件的時(shí)候, Linux下的epoll是異步讀,而Windows下的IOCP是同步讀,從后面的分析可以發(fā)現(xiàn),同步讀似乎更有優(yōu)勢(shì).
開始的時(shí)候,對(duì)于wait事件發(fā)生并進(jìn)行read的線程,并沒有提高其優(yōu)先級(jí),發(fā)現(xiàn)在過于頻繁的往目錄下添加文件和目錄的時(shí)候,會(huì)丟事件.這樣在做實(shí)時(shí)同步時(shí),要想辦法彌補(bǔ)丟失的事件.
第一個(gè)方案是對(duì)新添加的目錄,先把目錄add_watch,然后把該目錄掃描一遍.add_watch只是為了確保新建目錄被加入watch,一般不會(huì)漏掉的,除非是在事件被漏掉的情況下.漏掉指的是在目錄新建并上報(bào)到加入watch前的這段時(shí)間,在該目錄下又發(fā)生了新建文件或目錄時(shí),會(huì)漏事件. iNotify是允許對(duì)同一個(gè)目錄add_watch兩遍的,但是由于add時(shí)還要訪問硬盤,確保目錄存在才能添加,所以做了一個(gè)緩存,path<--->wd,通過path的查找確定是否已a(bǔ)dd_watch,若沒add再add下.
第一個(gè)方案里漏事件的問題通過事后掃描得到解決,但是再掃描一遍是否有意義呢? 分析了Linux的線程有限級(jí)和調(diào)度策略之后,發(fā)現(xiàn)實(shí)時(shí)優(yōu)先級(jí)有兩種SCHED_FIFO和SCHED_RR.從Linux kernel development里chapter4 RealTime看到：
“SCHED_RR is identical to SCHED_FIFO except that each process can run only until it exhausts a predetermined timeslice. That is, SCHED_RR is SCHED_FIFO with timeslicesit is a real-time round-robin scheduling algorithm. When a SCHED_RR task exhausts its timeslice, any other real-time processes at its priority are scheduled round robin. The timeslice is used only to allow rescheduling of same-priority processes.”
這也就是說,若是把讀事件的線程設(shè)置為FIFO,則沒有timeslice的限制,可以直到讀完事件,并且不會(huì)被搶占;而用RR則在timeslice用完一個(gè)之后,就會(huì)調(diào)度到別的線程,覺得可以用FIFO的設(shè)置來替代低效的掃描。
注1:
設(shè)置線程策略可以用下面的api:
- pthread_attr_getschedpolicy(const pthread_attr_t *restrict attr, int *restrict policy);
- pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy );
設(shè)置線程優(yōu)先級(jí)可以用下面的api:
- int sched_get_priority_max(int policy);
- int sched_get_priority_min(int policy);
- int pthread_attr_getschedparam(const pthread_attr_t *restrict attr,
- struct sched_param *restrict param);
- int pthread_attr_setschedparam(pthread_attr_t *restrict attr,
- const struct sched_param *restrict param);
- struct sched_param sched;
- sched.sched_priority = sched_get_priority_max(SCHED_FIFO);
- pthread_attr_setschedparam( attr, &sched );
第二個(gè)方案的產(chǎn)生是因?yàn)樵趯?shí)現(xiàn)了第一個(gè)方案之后,發(fā)現(xiàn)多CPU或多core的情況下,仍然有漏報(bào)事件發(fā)生,而且漏報(bào)無規(guī)律可循,文件或目錄的個(gè)數(shù)不定,.再做了多種模擬測(cè)試之后,發(fā)現(xiàn)在單CPU下,讀事件是沒有問題的,但是在多CPU下,讀事件的線程是分配了core的個(gè)數(shù)個(gè)的.這時(shí)會(huì)發(fā)現(xiàn)讀到的事件不是一般的亂,而且無規(guī)律可循.在沒有任何分析的情況下,我假定inotify會(huì)對(duì)他內(nèi)部的RB-Tree的讀取做了同步的,所以為了效率就肆無忌憚的用多個(gè)線程去讀了,結(jié)果在多U下,就給讀亂了.在把讀取線程改為一個(gè)后,就沒有漏事件了;但是考慮到效率問題,還是要用多個(gè)線程去讀的.或者可以對(duì)每個(gè)線程的read進(jìn)行加鎖,這樣就可以保證讀的時(shí)候,在iNotify的buffer里是同步的了.具體效果如何,還有待明天驗(yàn)證;
在這里插一句,Windows的iocp是同步讀的,是先read然后再getiocpstatus的,Linux的Epoll是反過來的,是異步讀取的.個(gè)人覺得可能是ms已經(jīng)對(duì)異步讀的方式進(jìn)行了測(cè)試,最后選定了同步讀的方式,這樣對(duì)寫應(yīng)用的人來說,是要省不少心的.而且還有一點(diǎn),inotify沒有加迭代監(jiān)控子目錄的參數(shù),而Windows卻有了這種考慮,這一點(diǎn)也算是win在設(shè)計(jì)上考慮比較全面的地方吧.
【編輯推薦】
