You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DTD uses termination_detected() to destroy the taskpool,
and on_leave_wait() to reset the taskpool and reinitialize
the termination detector.
The 'local' termination detector module had a race condition:
it would mark the taskpool as 'terminated', then call the
termination_detected() callback.
As any thread can detect the termination, a worker thread could
enter taskpool destruction in parallel with the main thread
calling on_leave_wait() because taskpool_state() has returned
TERMINATED already.
Thus, the taskpool could be destroyed *after* its termination
detector is reset, leading to asserts.
Proposed solution consists of adding an intermediary state in
the termination detector, 'TERMINATING'. TERMINATING is shown
as 'BUSY' to the scheduler, so the main thread does not return
from the main loop and does not call on_leave_wait() while the
thread that detected termination is still executing
termination_detected(). TERMINATING is still a necessary
intermediary step in order to ensure that only one thread calls
termination_detected().
Solves issue ICLDisco#634
Describe the bug
Seen only once on #321, need to see if it also happens on master
To Reproduce
The text was updated successfully, but these errors were encountered: