pthread_mutex_lock doesn't interrupt

[Corvus Corax]

Hi

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 :)

Andy wrote:

> 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?
> 
> Andy

PTHREAD_MUTEX_LOCK() has been defined in IEEE POSIX 1003.1c.

From the POSIX Programmers Manual:

http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

> 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)

regards

Corvus

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple