Fix a race condition in the thread exit/join code in DeterministicSchedule.
Summary: Previously, there was a race between exitingSems_[...] = tls.sem (in beforeThreadExit) and exitingSems_[...].post() (in joinAll). The race exists because exitingSems_ is a map that is not protected by the "shared access" synchronization mechanism used by DeterministicSchedule (i.e. it does not sit between a beforeSharedAccess and afterSharedAccess pair). Specifically, the main thread can be reading exitingSems_ while a child thread is writing to it. This diff fixes that: after all threads are ready to exit (this part isn't changed), we first wait for the joiner thread itself to be scheduled, and then, it will post the semaphore to wake up the child thread to run its thread-local destructors, and at the same time call .join() on the child. All this runs in a "critical section" between beforeSharedAccess and afterSharedAccess in the joiner thread. For clarity also changed the child thread to use descheduleCurrentThread, and to make the DeterministicSchedule destructor no longer call beforeThreadExit since it makes little sense. Reviewed By: yfeldblum Differential Revision: D23119075 fbshipit-source-id: 22bc6ffd9a9d888cc09bdee066dcac7f05b29fa7
Showing
Please register or sign in to comment