Shared Source CLI Essentials

Suspending and Resuming PAL Threads

Now that we have discussed synchronization and signaling within the Unix PAL, we can see them in action in the way that PAL threads are suspended and resumed. Although the POSIX threads package meets most of the PAL’s requirements, the pthread API does not contain a standard way to suspend or resume a thread. To further complicate matters, PAL threads must be able to suspend themselves, and they should be capable of tracking and recovering from multiple requests for suspension by maintaining a suspend count. (Nonstandardized extensions to pthreads certainly exist, such as FreeBSD’s pthread_suspend_np and pthread_resume_np functions, but none of these fully capture the PAL’s Win32 semantics.)

To implement self-suspension, the code in SuspendThread waits on the thread’s blocking pipe until another thread calls ResumeThread , which resumes the thread by writing to the pipe. Since this use of the blocking pipe (an expensive resource to allocate on a per-thread basis) is shared with the signaling mechanism described in “Implementing Signaling,” the SuspendedWithPipeFlag in the THREAD structure is used to indicate when the pipe is being utilized for suspension rather than for waiting.

When suspending another thread, platform-specific approaches are used. On FreeBSD, SuspendThread utilizes the pthread_suspend_np routine, keeping a suspension count in the field dwSuspendCount. On Mac OS X, the pthread_t is converted to a Mach thread ID, and thread_suspend ...