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