This is the mail archive of the
mailing list for the Cygwin project.
Re: pthread_mutex_lock doesn't interrupt
I did read your other response, regarding the signal developer being on
vacation. I'm sending this just for reference, since I had already
looked it up anyway :)
> Have you got chapter and verse from the POSIX standard on that? By
> 'interrupt' do you mean SIGINT or any signal? Is it possible that the
> signal is just being deferred and then subsumed by later signals?
PTHREAD_MUTEX_LOCK() has been defined in IEEE POSIX 1003.1c.
From the POSIX Programmers Manual:
> If a signal is delivered to a thread waiting for a mutex, upon
> return from the signal handler the thread shall resume waiting
> for the mutex as if it was not interrupted.
As you can see from the test cases (attached to the other mail)
only one type of signal (SIGUSR1) is repeatedly sent, but not handled.
I am not sure if I understood what you mean by "deferred".
It is possible (though in our case irrelevant) that the cygwin code
WOULD still call the signal handler AFTER pthread_mutex_lock() returns.
However in the FreeRTOS code this never happens, since the failure of
executing the signal handler even on repeated signals results in the
mutex in question not being released -> deadlock!
(Another thread holds the mutex but waits for the signal handler
to acknowledge the signal reception before releasing it)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple