（讀寫鎖優先級 寫飢餓）：
對一個同享的數據布局,讀的頻率遠弘遠於寫,所以用了讀寫鎖.但是發現寫線程老是搶不到鎖.
按The Open Group 的Single UNIX? Specification所說，"Thepthread_rwlock_rdlock() function applies a read lock to the read-write lock referenced by rwlock. The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock. It is unspecified whether the calling thread acquires the lock when a writer does not hold the lock and there are writers waiting for the lock" 貌似意思是說，沒有writer在持有寫鎖的時，reader是可以拿到讀鎖的。然則沒有划定，若是有writer在等寫鎖，該若何？
自己測試結果：
對於ACE_RW_Mutex，當幾個線程不斷獲取釋放讀鎖，各讀線程使用鎖的時間疊加，鎖講一直處於被讀取狀態，此時加寫鎖，寫線程將一直處於等待狀態。
即ACE_RW_Mutex 並不保證讀寫鎖請求和處理時序。讀鎖獲條件是只要當前鎖沒有被別人以寫方式獲取就可以獲取到讀權限。
這樣做的優勢是由於讀鎖可並發執行，提高CPU利用率。缺點是在讀鎖使用頻度較高情況下，會出現不斷有線程使用讀鎖，寫鎖線程飢餓等待。
pthread_rwlockattr_setkind_np 應該可以調整讀寫鎖優先級順序。
示例如下：
pthread_rwlockattr_t attr;
pthread_rwlockattr_init(&attr);
pthread_rwlockattr_setkind_np (&attr, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP);
(void)pthread_rwlock_init(&rwlock, &attr);
（鎖競爭引發的高系統調用）：
遇到一個場景，多線程情況下出現了超高頻的讀寫鎖的讀鎖訪問，然后就發現該場景下內核態CPU很高，感覺很可能與讀寫鎖實現機制有關，讀鎖的成功申請同樣會觸發內核態調用，比如使用到了內核態的鎖實現了讀寫鎖。