Linux事件監(jiān)控機制遺漏事件問題的相關(guān)分析
目前比較通用的監(jiān)控Linux下文件系統(tǒng)變化的是Epoll+iNotify結(jié)合的機制.
Epoll有兩種機制,LevelTrigger和EdgeTrigger, 前者相當(dāng)于fast poll, 后者可以理解為對nonblocking fd的阻塞化, 這個說法嚴(yán)格來講有點兒業(yè)余,只是為了簡單的說明問題.
對于從epoll_wait等待事件觸發(fā),然后進行read.這里做下說明,在讀事件的時候, Linux下的epoll是異步讀,而Windows下的IOCP是同步讀,從后面的分析可以發(fā)現(xiàn),同步讀似乎更有優(yōu)勢.
開始的時候,對于wait事件發(fā)生并進行read的線程,并沒有提高其優(yōu)先級,發(fā)現(xiàn)在過于頻繁的往目錄下添加文件和目錄的時候,會丟事件.這樣在做實時同步時,要想辦法彌補丟失的事件.
第一個方案是對新添加的目錄,先把目錄add_watch,然后把該目錄掃描一遍.add_watch只是為了確保新建目錄被加入watch,一般不會漏掉的,除非是在事件被漏掉的情況下.漏掉指的是在目錄新建并上報到加入watch前的這段時間,在該目錄下又發(fā)生了新建文件或目錄時,會漏事件. iNotify是允許對同一個目錄add_watch兩遍的,但是由于add時還要訪問硬盤,確保目錄存在才能添加,所以做了一個緩存,path<--->wd,通過path的查找確定是否已add_watch,若沒add再add下.
第一個方案里漏事件的問題通過事后掃描得到解決,但是再掃描一遍是否有意義呢? 分析了Linux的線程有限級和調(diào)度策略之后,發(fā)現(xiàn)實時優(yōu)先級有兩種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的限制,可以直到讀完事件,并且不會被搶占;而用RR則在timeslice用完一個之后,就會調(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)先級可以用下面的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 );
第二個方案的產(chǎn)生是因為在實現(xiàn)了第一個方案之后,發(fā)現(xiàn)多CPU或多core的情況下,仍然有漏報事件發(fā)生,而且漏報無規(guī)律可循,文件或目錄的個數(shù)不定,.再做了多種模擬測試之后,發(fā)現(xiàn)在單CPU下,讀事件是沒有問題的,但是在多CPU下,讀事件的線程是分配了core的個數(shù)個的.這時會發(fā)現(xiàn)讀到的事件不是一般的亂,而且無規(guī)律可循.在沒有任何分析的情況下,我假定inotify會對他內(nèi)部的RB-Tree的讀取做了同步的,所以為了效率就肆無忌憚的用多個線程去讀了,結(jié)果在多U下,就給讀亂了.在把讀取線程改為一個后,就沒有漏事件了;但是考慮到效率問題,還是要用多個線程去讀的.或者可以對每個線程的read進行加鎖,這樣就可以保證讀的時候,在iNotify的buffer里是同步的了.具體效果如何,還有待明天驗證;
在這里插一句,Windows的iocp是同步讀的,是先read然后再getiocpstatus的,Linux的Epoll是反過來的,是異步讀取的.個人覺得可能是ms已經(jīng)對異步讀的方式進行了測試,最后選定了同步讀的方式,這樣對寫應(yīng)用的人來說,是要省不少心的.而且還有一點,inotify沒有加迭代監(jiān)控子目錄的參數(shù),而Windows卻有了這種考慮,這一點也算是win在設(shè)計上考慮比較全面的地方吧.
【編輯推薦】
