From owner-freebsd-questions@freebsd.org Wed Aug 7 12:51:28 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 C5C5AAA602; Wed, 7 Aug 2019 12:51:28 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 463WbM48LNz3CPx; Wed, 7 Aug 2019 12:51:27 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.15.2/8.15.2) with ESMTP id x77CpNis037004; Wed, 7 Aug 2019 13:51:23 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id x77CpMUY024560; Wed, 7 Aug 2019 13:51:22 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id x77CpMfL024556; Wed, 7 Aug 2019 13:51:22 +0100 Date: Wed, 7 Aug 2019 13:51:22 +0100 Message-Id: <201908071251.x77CpMfL024556@higson.cam.lispworks.com> From: Martin Simmons To: Konstantin Belousov CC: freebsd.ed.lists@sumeritec.com, deischen@freebsd.org, freebsd-questions@freebsd.org, freebsd-threads@freebsd.org In-reply-to: <20190807092035.GG2731@kib.kiev.ua> (message from Konstantin Belousov on Wed, 7 Aug 2019 12:20:35 +0300) Subject: Re: mutex held in a thread which is cancelled stays busy 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> X-Rspamd-Queue-Id: 463WbM48LNz3CPx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of martin@lispworks.com has no SPF policy when checking 46.17.166.21) smtp.mailfrom=martin@lispworks.com X-Spamd-Result: default: False [0.41 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.24)[-0.237,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lispworks.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.35)[0.353,0]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.69)[-0.692,0]; RCVD_IN_DNSWL_NONE(0.00)[21.166.17.46.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:51055, ipnet:46.17.166.0/24, country:GB]; IP_SCORE(-0.02)[country: GB(-0.08)] 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 12:51:28 -0000 >>>>> On Wed, 7 Aug 2019 12:20:35 +0300, Konstantin Belousov said: > DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x779KZSe066777 > > 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. That is clear in POSIX, so should the FreeBSD man page be changed to say "process containing the owning thread" at least? Currently the section starts with: The pthread_mutex_lock() function will fail if: and the word "will" reads to me like a "shall", not a "may". Code relies on this interpretation of "will" in other man pages, e.g. for [EWOULDBLOCK] in accept(2). __Martin