From owner-freebsd-questions@freebsd.org Wed Aug 7 09:20:43 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 BD3DEC41A8; Wed, 7 Aug 2019 09:20:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463QwB67PLz4S10; Wed, 7 Aug 2019 09:20:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x779KZSe066777 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 12:20:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x779KZSe066777 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x779KZjh066773; Wed, 7 Aug 2019 12:20:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Aug 2019 12:20:35 +0300 From: Konstantin Belousov To: Erich Dollansky Cc: Daniel Eischen , freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <20190807092035.GG2731@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190807163757.2b5d52fa.freebsd.ed.lists@sumeritec.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 463QwB67PLz4S10 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.79)[-0.788,0]; IP_SCORE(0.00)[ip: (-2.65), ipnet: 2001:470::/32(-4.49), asn: 6939(-2.92), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] 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 09:20:43 -0000 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.