From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 16:48:15 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0A85410; Sun, 21 Jul 2013 16:48:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAC59B8; Sun, 21 Jul 2013 16:48:15 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6LGmENP029585; Sun, 21 Jul 2013 12:48:14 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Sun, 21 Jul 2013 12:48:14 -0400 (EDT) Date: Sun, 21 Jul 2013 12:48:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon Subject: Re: Mutexes and error checking In-Reply-To: <51EC0BCF.6080501@FreeBSD.org> Message-ID: References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe Marcus Clarke , Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:48:16 -0000 On Sun, 21 Jul 2013, Andriy Gapon wrote: > on 21/07/2013 19:02 Jilles Tjoelker said the following: >> So I think allowing pthread_mutex_unlock() by a different thread would >> be a step backwards. > > There is something else that bothers me too. > Properly written code always "knows" whether it has a lock or not. It does not > try to unlock on a whim. Apparently the software in question is not properly > written. Nevertheless, it takes care to check return status of > pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific > behavior in doing so. That seems like "two wrongs make a right" thing. > > I understand that "life is such", etc, but it hurts to see us bend for such a > backwards code. I agree that this seems like broken software (threads releasing locks they don't own), but _if_ PTHREAD_MUTEX_NORMAL was explicitly set by the software, it could mean two things: o Assumption that PTHREAD_MUTEX_NORMAL mutexes are inherently faster than PTHREAD_MUTEX_DEFAULT, or o The behavior of this type of mutex, at least in regard to the unlock, is desired. For the latter case, I'm thinking specifically of thread-safe libraries. Maybe they don't care (in these unlock cases) because they know at the time that whatever the mutexes are protecting is stable. They could use robust mutexes, but they may not be as widely implemented. I think most folks assume that PTHREAD_MUTEX_NORMAL are the faster of the POSIX specified mutex types, but POSIX makes no such guarantee. I think perhaps they need a PTHREAD_MUTEX_FAST or to just specify that it is the implementations fastest type of POSIX mutex. -- DE