From owner-freebsd-threads@freebsd.org Thu Aug 8 06:10:49 2019 Return-Path: Delivered-To: freebsd-threads@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 E0AEBC4488; Thu, 8 Aug 2019 06:10:49 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from out2-4.antispamcloud.com (out2-4.antispamcloud.com [185.201.17.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 463yfZ4BH8z3P6w; Thu, 8 Aug 2019 06:10:46 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from srv31.niagahoster.com ([153.92.8.106]) by mx61.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hvbdJ-0009OD-BC; Thu, 08 Aug 2019 08:10:44 +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=Ti5+zI7Sxs/SH2VswNZtXB4EJcKahAfBaDTv/C+I1F4=; b=cNu2WU4fi508m+NkZHgVrmYnGg TBnKGZWs57hH5eakOMWyTTsO6MvX+cRPlaqKR3hhfpX3ZkTdkWuGM5hw9aE0vhhwSFJjjGAKYO++U tVcOJJl/u3adMUkmZUVxPXwdFVbwIZURYTvLlPYJXmo13smLNe/UmINNZqUQWEMRIE7z5zwXFZWBo Oww2mtVUKz65GFn2U2AfaV/G7uT6OLzg0CbzcQ0M0S/DK1Focc/Tk9NPGgjRW+PxqrzpaOoHnoTvQ rlkIxoqc6XK6UTdQPRiOIWtow690868mpfne8kWM9wLwtR7LbAO4EOoveD9LoEtEBN+HryyND3I1O sAyP4v0w==; Received: from [114.125.119.173] (port=52152 helo=Ryzen1.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hvbcS-0003zv-9N; Thu, 08 Aug 2019 13:09:54 +0700 Date: Thu, 8 Aug 2019 14:09:45 +0800 From: Erich Dollansky To: Daniel Eischen Cc: freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <20190808140945.7eb235aa.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> <20190807182548.1a8e00dd.freebsd.ed.lists@sumeritec.com> 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+Jt8z2T3KvyegFAN3MVG+8Mu8M+ESLE+f zSH/OCabdgYrKxSFlmzsjsh6g2fcHOa7vk9G8zr0q4944rEFsbYm0DdSDY/HgkGlz8CJSOMrvzx9 TVg3RkVeBrZaDk7xAYrZ2BK/Q+Mop8jZ4AoGBlDR94YkH0RjFQmsAcf1kLoKapRG7lc9JeDN7KHQ l3eg3qrfFG24mhAbgq187NiIKOf+KSg+XppMqz7bfuwlcJJEKTupS5XvURwhEWyJzIkwSFAW0Pw8 uiKeMUJTS2Jsxpkx+IHIsDarm2Hx5e4YMH5a+Vxo+Gz4gw56nrUo2iUXYOUfZrYt2kwya2u/aJSy +XYIL3TVXRgGu+ISfO+8Nwazmqab1cMTal0k88rkq0CsLjZ84JRIA6Ye/ajVf3YKfhRT0knXt1CR LuLMOPhV8sZiFXmtTilamlYRFmMy/B+9uFk6vL63wFNT/iH+i0krVjPg4j89ZZyO7mN7AnWnYo04 a2ey4hx/dv+muc596OjLSvKX9IT2wJHgmTBPB3ojkwVz5nkXGxmpgHMcN6qoXPjenLhIOF1oeRbs um4BtTmK88nRNTFa+st+XaoInkRdNlt33zOhWO9WO0TWS/svbnV0qSBFjIWKltiA4C3fxV8V8Cbn AWESwbg6xu2OfQrGyuxJBL08Tx1B6MUXC2YrxA3JqQGzPWUXNAL5luHEIOz7YnQP9uRZXMDdNgA/ bvpxeniqBDKdL+6MGbK4t8eoCcCPuuAofv54KaaefG3Qi6AvJQbthcIFXjU5VKFwDpe+9rZABUSO mrMA1sfhtY1GZZolCkLnLN7c0R+MPCdbWjlZ4FwOnzX+Io4BoxTkj0hGlATQgXlJtJ0i5pE2QAQR POB84MmsDrk3yRlOP34VGRo5L8M2MA2Zvy07rVJth1gDB2lpXMdbvAc7tiERbInMiTBIUBbQ/Dy6 Ip65tyiUWX+tf7ZF5CSWokMB/eSqQACX6tONkFbPlnFTwFrgPv9TQfT8VfEBrwtfkhA= X-Report-Abuse-To: spam@quarantine10.antispamcloud.com X-Rspamd-Queue-Id: 463yfZ4BH8z3P6w X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sumeritec.com header.s=default header.b=cNu2WU4f; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd.ed.lists@sumeritec.com has no SPF policy when checking 185.201.17.4) smtp.mailfrom=freebsd.ed.lists@sumeritec.com X-Spamd-Result: default: False [-0.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sumeritec.com:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.977,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sumeritec.com]; NEURAL_HAM_MEDIUM(-0.98)[-0.977,0]; NEURAL_SPAM_SHORT(0.56)[0.556,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[sumeritec.com:+]; MID_CONTAINS_FROM(1.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[4.17.201.185.list.dnswl.org : 127.0.3.1]; RECEIVED_SPAMHAUS_PBL(0.00)[173.119.125.114.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49544, ipnet:185.201.17.0/24, country:NL]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-0.05)[ip: (1.27), ipnet: 185.201.17.0/24(-1.27), asn: 49544(-0.24), country: NL(0.01)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 06:10:49 -0000 Hi, On Wed, 7 Aug 2019 13:26:31 -0400 Daniel Eischen wrote: > > On Aug 7, 2019, at 6:25 AM, Erich Dollansky > > wrote: > > > > 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. > > In this case, I think FreeBSD is behaving correctly. I think perhaps > the only problem is that the man page isn't reflecting the POSIX > wording. > it is not so clear. This is also the reason why I finally relied on the FreeBSD man page. It says at the bottom: The pthread_mutex_lock() function conforms to ISO/IEC 9945-1:1996 ("POSIX.1"). Which is pretty old. http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) ... When you check that document out, it becomes even more confusing as it says in one case 'thread' and in the other case 'process'. This makes it a bit confusing for programmers as especially the unlock function should be only called by the thread holding the lock. How this was defined by the FreeBSD manuals made it very clear to programmers.. To come back to your comment. So, even when we assume the Open Group has the final say, pthread_mutex_unlock is wrong as it shall release the mutex when held by a dead thread but it does not. The whole thing looks to me that the author of the man page used some logic which did not make it into the software. Erich