Hi all.
I believe there is a bug in event_base_loop() function from file event.c
(opal/mca/event/libevent2022/libevent/).
Consider the case when application is going to be finalized and both
event_base_loop() and event_base_loopbreak() are called in the same time
in parallel threads.
Then if event_base_loopbreak() happens to acquire lock first, it will
set "event_base->event_break = 1", but won't send any signal to event
loop, because it did not started yet.
After that, event_base_loop() will acquire the lock and will clear
event_break flag with the following statement: "base->event_gotterm =
base->event_break = 0;". Then it will go into polling with timeout = -1
and thus block forever.
This issue was reproduced on a custom compiler (using Lulesh benchmark
and x86 4-core PC), but it can be also reproduced for me with GCC
compiler (on almost any benchmark and in same HW settings) by putting
some delay to orte_progress_thread_engine() function:
static void* orte_progress_thread_engine(opal_object_t *obj)
{
while (orte_event_base_active) {
usleep(1000); // add sleep to allow orte_ess_base_app_finalize()
set orte_event_base_active flag to false
opal_event_loop(orte_event_base, OPAL_EVLOOP_ONCE);
}
return OPAL_THREAD_CANCELLED;
}
I am not completely sure what should be the best fix for described problem.