Deadlock risk in _pthread_removeThreadKeys() [SYS/BIOS]

There is a call to Semaphore_pend() in _pthread_removeThreadKeys() which may lead to deadlock. Consider a thread calling pthread_getspecific(), which takes the semaphore. While holding the semaphore, it is preempted by a higher priority thread which calls pthread_cancel() on the previous thread. The thread cancel processing will disable the previous thread (i.e. it will never run again) and then calls _pthread_removeThreadKeys(), which attempts to take the same semaphore (currently held by the now disabled thread). The higher priority thread blocks forever. This should be handled by using the cancel state to defer thread cancelation while holding the semaphore. _pthread_removeThreadKeys() must still use the semaphore to protect the list operations in case yet another thread is adding or removing an item from the list.