All content and materials on this
site are provided "as is". TI and its respective suppliers and providers of content make no representations about
the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these
materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a
particular purpose, title and non-infringement of any third party intellectual property right. No license, either
express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a
license from a third party, or a license from TI.
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.
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.
Deadlock risk in _pthread_removeThreadKeys() [SYS/BIOS]