From owner-freebsd-threads@freebsd.org Wed Aug 7 17:26:34 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 01316B1C1C; Wed, 7 Aug 2019 17:26:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463dhn4jj4z42yB; Wed, 7 Aug 2019 17:26:33 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.0.0.52] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id x77HQVR7022963 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Aug 2019 13:26:31 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 07 Aug 2019 13:26:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: mutex held in a thread which is cancelled stays busy From: Daniel Eischen X-Mailer: iPhone Mail (16G77) In-Reply-To: <20190807182548.1a8e00dd.freebsd.ed.lists@sumeritec.com> Date: Wed, 7 Aug 2019 13:26:31 -0400 Cc: freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Erich Dollansky X-Rspamd-Queue-Id: 463dhn4jj4z42yB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.84 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; NEURAL_HAM_LONG(-0.86)[-0.858,0]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] 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: Wed, 07 Aug 2019 17:26:34 -0000 > On Aug 7, 2019, at 6:25 AM, Erich Dollansky wrote: >=20 > Hi, >=20 > On Wed, 7 Aug 2019 06:07:25 -0400 > Daniel Eischen wrote: >=20 >>> On Aug 7, 2019, at 5:20 AM, Konstantin Belousov >>> wrote:=20 >>>> On Wed, Aug 07, 2019 at 04:37:57PM +0800, Erich Dollansky wrote: >>>> Hi, >>>>=20 >>>> On Wed, 7 Aug 2019 10:10:02 +0300 >>>> Konstantin Belousov wrote: >>>>=20 >>>>>>> On Tue, Aug 06, 2019 at 08:58:30PM -0400, Daniel Eischen wrote: >>>>>>>=20 >>>>>>> On Aug 6, 2019, at 4:54 AM, Erich Dollansky >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> for testing purpose, I did the following. >>>>>>>=20 >>>>>>> Start a thread, initialise a mutex in a global variable, lock >>>>>>> the mutex and wait in that thread. >>>>>>>=20 >>>>>>> Wait in the main program until above's thread waits and cancel >>>>>>> it. >>>>>>>=20 >>>>>>> Clean up behind the cancelled thread but leave intentional the >>>>>>> mutex locked. >>>>>>>=20 >>>>>>> I would have expected now to get an error like 'EOWNERDEAD' >>>>>>> doing operations with that mutex. But I get 'EBUSY' as the >>>>>>> error. =20 >>>>>>=20 >>>>>> Are you initializing the mutex as a robust mutex, via >>>>>> pthread_mutexattr_setrobust()? Are you using _lock() or >>>>>> _trylock()? =20 >>>>> Robust mutexes only have special properties on the process >>>>> termination. They behave same as the normal mutexes if the owning >>>>> thread is terminated. >>>>>=20 >>>> man says: >>>>=20 >>>> [EOWNERDEAD] The argument mutex points to a robust mutex and the >>>> previous owning thread terminated while holding the mutex lock. =20 >>>=20 >>> So what ? It describes the case when error can be returned, but it >>> is not required to do so. POSIX wording is the following: >>>=20 >>> 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. >>>=20 >>> 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. =20 >>=20 >> 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. >>=20 >> Erich, are you getting EBUSY for pthread_mutex_lock() or is that only >> for pthread_mutex_trylock()? >>=20 > 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 on= ly problem is that the man page isn't reflecting the POSIX wording. -- DE=