Fix dynamic thread destruction race
Summary: There is a subtle race between thread destruction and task addition (ensureActiveThreads). For an executor with a single thread, the race would be: threadid 1 cpu thread returns from try_take_for by timing out. 2 someone from a different thread calls add() 2 add() finds lifosem empty, calls ensureActiveThreads 2 ensureActiveThreads grabs the lock, finds active=1, total=1, returns doing nothing, assuming thread is still running. 1 cpu thread decrements activeThreads_ to 0 in taskShouldStop. There are now *no* threads running until the next call to add(), and one task waiting. Fix: Grab lock in taskShouldStop (like the documentation says we should be doing). Also double check that there are no currently pending tasks. This probably only affects pools with size of 1, otherwise we would have added a second thread and there may temporarily be one fewer threads running. Reviewed By: davidtgoldblatt Differential Revision: D7943241 fbshipit-source-id: 502e5809ccf4ecca85205c14c4d97b508897de9b
Showing
Please register or sign in to comment