2017-04-18 100 views
1

在庫中pthread.hpthread_rwlock_t FIFO?pthread讀寫鎖定FIFO?

在下面的例子中,我們有多個線程。想象一下,每個線程都保證按順序運行。

// Thread 1 - does a write lock 
pthread_rwlock_wrlock(&lock); 

// Thread 2 - does a read but has to wait for 1 
pthread_rwlock_rdlock(&lock); 

// Thread 3 - does a read but has to wait for 1 
pthread_rwlock_rdlock(&lock); 

// Thread 4 - does a write but has to wait for 1 
pthread_rwlock_wrlock(&lock); 

// Thread 1 - unlocks 
pthread_rwlock_unlock(&lock); 

// who gets the lock? 

線程1釋放鎖後,誰鎖?是否保證線程2和線程3?或者它可能被給予4?

再次,想象一下,每個線程都保證按順序運行,線程1不會釋放鎖,直到所有線程都試圖獲得鎖。

+1

我認爲這個詞在這裏不適用。線程不保證以任何順序運行。對這些事情做出假設通常會導致多線程問題。你的_imagine_短語是毫無意義的,因爲它實際上是另一種方式:獲得鎖定的線程是將要運行的線程。 – VTT

+0

你可以在'thread 1'上調用'join',並保證它們等待'thread 1'完成。至於'''線程不保證以任何順序運行「,這不一定是正確的,因爲它取決於鎖的調度策略。如果不是'讀寫'鎖,我們有一個簡單的'互斥鎖',我們可以保證這些線程按照'mutex'中的'FIFO'調度策略的順序運行。 –

回答

1

我做了一些研究,發現this document from the Oracle website解釋了pthread讀寫鎖的調度策略。

如果與pthread_rwlock_unlock()的調用導致讀寫鎖定對象成爲解鎖並且有多個線程等待獲取讀寫鎖定對象進行寫入,所述調度策略被用於確定哪個線程獲取用於寫入的讀寫鎖對象。如果有多個線程等待讀取讀寫鎖對象,則調度策略用於確定等待線程獲取讀寫鎖對象的順序。 如果在讀鎖和寫鎖時rwlock上有多個線程被阻塞,那麼讀者是先獲取鎖還是寫者是否首先獲取鎖,這是未指定的。

因此,總而言之,它們不保證是FIFO。