From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 18:30:01 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 1ECFFCDB; Sun, 21 Jul 2013 18:30:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F0C6DC77; Sun, 21 Jul 2013 18:29:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA02011; Sun, 21 Jul 2013 21:29:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0yOL-000KLU-25; Sun, 21 Jul 2013 21:29:57 +0300 Message-ID: <51EC286D.4080208@FreeBSD.org> Date: Sun, 21 Jul 2013 21:29:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joe Marcus Clarke , Koop Mast , freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 18:30:01 -0000 on 21/07/2013 19:48 Daniel Eischen said the following: > 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. Well, my opinion is that either you want error checking or not. In the former case you use robust mutex and do other kinds of checks (like return code of pthread_* functions), in the latter case you use normal mutex, but then you don't do any return code checking. Mixing the two approaches and expecting something sane is... insane :-) JIMHO, of course. -- Andriy Gapon