Commit abb56764 authored by Committed by Halim AmerBrowse files
Fix arbitrary poll count before yielding.
Instead of polling for an arbitrarily decided number of times in the progress engine before yielding, we now moved the yielding intelligence to the threading layer. The threading layer can keep track of other threads that are waiting to enter the critical section and only yield if another thread is waiting. In this way, if no thread is waiting to get the lock, the main thread never yields. At the same time, if another thread is waiting to get a lock, there is no delay in yielding. This change, however, introduces possible deadlocks. If a thread enters MPIDI_CH3I_progress with is_blocking unset, it may set the MPIDI_CH3I_progress_blocked flag and then will yield the critical section. Another thread may enter with is_blocking set, find the flag MPIDI_CH3I_progress_blocked set, and block in the conditional variable. The first thread will wake up and leave the progress engine without emitting any signal to wake up the second thread which may sleep forever. A simple fix is to yield the critical section only if the current thread entered the progress engine with is_blocking set. Signed-off-by: Halim Amer <firstname.lastname@example.org>