X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org X-Spam-CYBERTRENCH-Report: SpamAssassin 3.2.1-gr2 (2007-05-02) on cybertrench.com hits: -0.7 of 7.0 Bayes: memorize=no score=0.5000 * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% * [score: 0.5000] * 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. X-Spam-CYBERTRENCH-Level: -0.7 X-cybertrench.com-virus-scan: clean Date: Tue, 13 Jul 2010 09:07:55 +0200 From: Corvus Corax To: cygwin@cygwin.com Subject: Re: pthread_mutex_lock doesn't interrupt Message-ID: <20100713090755.31f0664f@CorvusMC.home> In-Reply-To: References: <20100712230519.4e871a91@CorvusMC.home> References: <20100712230519.4e871a91@CorvusMC.home> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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? >=20 > Andy PTHREAD_MUTEX_LOCK() has been defined in IEEE POSIX 1003.1c. =46rom 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