From owner-freebsd-questions@freebsd.org Wed Aug 7 10:26:07 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 334ADC5BC3; Wed, 7 Aug 2019 10:26:07 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from out1-4.antispamcloud.com (out1-4.antispamcloud.com [185.201.16.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463SMg0Vylz4Wxp; Wed, 7 Aug 2019 10:26:06 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from srv31.niagahoster.com ([153.92.8.106]) by mx105.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hvJ8r-0004v1-QK; Wed, 07 Aug 2019 12:26:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tfRLMrDcuBwcTC9SFSToRZvUgwSzNJdCSI/KFUT5kl8=; b=mBThAOQq45qs0VV7G9STw4+eMS fNDvAgw/GgGUMpE9Lexfx1OvoHO6NsG7HFGTaBEOpRg1BDClRTUCc55azuKMCwahuYE5tiveqIyKh SrBfQXN8uLjKSq3iOd8AhFskQRLYEaHR4dFWfcK7EvBdeyRGtQ5YLXDLnziuAi1M0IgcyILjTDZLo lqX+gMdnw6QA2bFtg4rJllXskFaNkBiYz+HqehDHMjgYMrEcoOZq1dz8fnVK1TzYxXYKtP5yECSCI rHDwNxRKz7QZkT7lpUKyKB+NPObRTWFq2DGahDWoIqYpVDPpfc77VFszLtmCQR4oY7LeB5togd/PT jDW9w8GA==; Received: from [114.125.102.203] (port=18898 helo=Ryzen1.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hvJ8g-0000wy-B7; Wed, 07 Aug 2019 17:25:56 +0700 Date: Wed, 7 Aug 2019 18:25:48 +0800 From: Erich Dollansky To: Daniel Eischen Cc: Konstantin Belousov , freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <20190807182548.1a8e00dd.freebsd.ed.lists@sumeritec.com> In-Reply-To: References: <20190806165429.14bc4052.freebsd.ed.lists@sumeritec.com> <1FC05CEB-982F-484F-9E41-5A74FF564494@freebsd.org> <20190807071002.GF2731@kib.kiev.ua> <20190807163757.2b5d52fa.freebsd.ed.lists@sumeritec.com> <20190807092035.GG2731@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-Spampanel-Domain: out.niagahoster.com X-Spampanel-Username: niaga X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0YiRRkpbHZ8F3zevhEShTfypSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKyP9eGNFz9TW9u+Jt8z2T3KSZWQ0mYy/5bX2tR2MxjY1H8+ nrJQjYNop1GreY536hkFHlF5sjR4pyrimN8WEzK+lVo9zfgzQ4Wlm3+W3UHOXwrxwXFyuo2li+Ur O0gJPwiG34hmFjpyHQ7zdFs7vhS5FpdKWY4WDTNb/mmSaM4GPufHzJ6mVE7ewsipSVIfs4Zabjyj 3k9kwKzAqKFfV4UrpuYtsVhg3f/l2/mWu1Athhptu6CedWZCBcUv302F5j093s+AnbV2j8Ow/hRj vbRpAPk7YPj0OKe3lzpnlKaR3sSTXH+3izU4BB1VoFVxTkwhEWyJzIkwSFAW0Pw8uiKe7bgNQRm1 OeEwNfs/X7KNpm7JN07EVzkxDwUeUuKljznUAK0QEz1Q7JH7dxrZvW/0mJfHjaTCzOp63BMLs0qd SISbE1l0jCSqwqiEbnL4lT5T25bh8NcJDK50bxVgqERZsnxNd3HGmXwqaXdfIhxtGD/BNM8813zo gpOdGRAGcQuhFJ7oKehaoNVXSqhCqA/e/iH+i0krVjPg4j89ZZyO7hkDJRaaICR2rDamAVeZMV4D 7fKzXHKOS7epLutw5JLMllEIbIkVe06B7dx0jjZzY3McN6qoXPjenLhIOF1oeRbB0q/OPFFQP2A6 EGLaMo/P36WwUlIQ90Mu0vcNHQ67Fu4moKK5thEF3GBtlksvmTvbXxovJEd6WRmONQXAxSHs5oQB 9puMu8tmNfaWmneAreVHDK/d/D3POXDyR0+CAyjE04Qui3pq/43TyI+2Xq3sVLmn9E+h0mHeaLQF ksyUubCmFQOolhlV/ZRA5nHv4OPW7VqBA9oSlBsbfuqhpOn0f0yWjB8eiHqtxayLndn0kW27yM9f 1+Apz1RqILIQtFMEwq5bRwGe7jud07hsv+XycI/FXhRSOmUQhy9SmS81uJzRPA8gEmeeAc/z3AcE lOvzLPPdXnk9dTX03mZY8tOiLbdHLMfIRuttE8nKqCsLgpnckpWaLvahyBjmQxBKOzuWmKu/Exva /4bO4tpXcmDOqDCHuaY1ySl1jqLk9nhzO4M6gaq1aRjXtWVzuqGnWQc= X-Report-Abuse-To: spam@quarantine10.antispamcloud.com X-Rspamd-Queue-Id: 463SMg0Vylz4Wxp X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.945,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 10:26:07 -0000 Hi, On Wed, 7 Aug 2019 06:07:25 -0400 Daniel Eischen wrote: > > On Aug 7, 2019, at 5:20 AM, Konstantin Belousov > > wrote: > >> On Wed, Aug 07, 2019 at 04:37:57PM +0800, Erich Dollansky wrote: > >> Hi, > >> > >> On Wed, 7 Aug 2019 10:10:02 +0300 > >> Konstantin Belousov wrote: > >> > >>>> On Tue, Aug 06, 2019 at 08:58:30PM -0400, Daniel Eischen wrote: > >>>> > >>>>> On Aug 6, 2019, at 4:54 AM, Erich Dollansky > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> for testing purpose, I did the following. > >>>>> > >>>>> Start a thread, initialise a mutex in a global variable, lock > >>>>> the mutex and wait in that thread. > >>>>> > >>>>> Wait in the main program until above's thread waits and cancel > >>>>> it. > >>>>> > >>>>> Clean up behind the cancelled thread but leave intentional the > >>>>> mutex locked. > >>>>> > >>>>> I would have expected now to get an error like 'EOWNERDEAD' > >>>>> doing operations with that mutex. But I get 'EBUSY' as the > >>>>> error. > >>>> > >>>> Are you initializing the mutex as a robust mutex, via > >>>> pthread_mutexattr_setrobust()? Are you using _lock() or > >>>> _trylock()? > >>> Robust mutexes only have special properties on the process > >>> termination. They behave same as the normal mutexes if the owning > >>> thread is terminated. > >>> > >> man says: > >> > >> [EOWNERDEAD] The argument mutex points to a robust mutex and the > >> previous owning thread terminated while holding the mutex lock. > > > > So what ? It describes the case when error can be returned, but it > > is not required to do so. POSIX wording is the following: > > > > If mutex is a robust mutex and the process containing the owning > > thread terminated while holding the mutex lock, a call to > > pthread_mutex_lock() shall return the error value [EOWNERDEAD]. If > > mutex is a robust mutex and the owning thread terminated while > > holding the mutex lock, a call to pthread_mutex_lock( ) may return > > the error value [EOWNERDEAD] even if the process in which the > > owning thread resides has not terminated. > > > > Note the difference between shall and may. We only process robust > > list on the process termination. If the process is still alive, > > but the thread terminated, it can only happen because the process > > code asked for the thread termination explicitly, and then the code > > should be able to keep its own state. On really fatal conditions, > > like unhandled signals, kernel terminates the process, not a > > thread. > > But pthread_mutex_lock() should not return EBUSY; that is only for > _trylock(). It seems to me _lock() should either return EOWNERDEAD > or EDEADLK, or it just blocks indefinitely. > > Erich, are you getting EBUSY for pthread_mutex_lock() or is that only > for pthread_mutex_trylock()? > EBUSY is only returned when I call 'pthread_mutex_trylock'. The other one just hangs. Give me a bit if time and I will send you then a test program which is extracted from my test environment. Not that the error stems from very own test environment. Erich