From owner-freebsd-stable@FreeBSD.ORG Thu May 12 02:53:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DA9D16A4D3; Thu, 12 May 2005 02:53:31 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF1CA43D68; Thu, 12 May 2005 02:53:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j4C2rIBr011168; Wed, 11 May 2005 22:53:18 -0400 (EDT) Date: Wed, 11 May 2005 22:53:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jonathan Noack In-Reply-To: <4282C089.4070806@alumni.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Mikhail Teterin cc: re@freebsd.org cc: stable@freebsd.org Subject: Re: PTHREAD_INVARIANTS in 5.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 02:53:31 -0000 On Wed, 11 May 2005, Jonathan Noack wrote: > > I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT. > As far as I can tell, all but one of the defines under > _PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it > is false result in a fatal error. These should be very visible if they > are being tripped. Only MUTEX_INIT_LINK actually *does* something. It > is defined in src/lib/libpthread/thread/thr_mutex.c at lines 43-46 and > in src/lib/libthr/thread/thr_mutex.c at lines 44-47: > > #define MUTEX_INIT_LINK(m) do { \ > (m)->m_qe.tqe_prev = NULL; \ > (m)->m_qe.tqe_next = NULL; \ > } while (0) > > I'm not sure what impact removing this explicit initialization would > have. If we're not seeing fatal errors, everything else is just slowing > us down. Assuming we feel our thread implementations are production > worthy, we should disable these checks for releases. That is, unless I > am missing something... I wrote the darn things, and they are useful in that they can provide useful information if there are bugs and also for detecting if the application is linked to multiple thread libraries. For the init links macro, it is only used when the mutex is initialized and on unlock. It's two instructions. The others are also just a couple of instructions and shouldn't be called often. This is way overblown and they're other areas for much better optimizations than worrying about a couple of instructions. Perhaps if it were called _PTHREAD_ROBUST instead of _PTHREAD_INVARIANTS, noone would notice ;-) That's the last I'll say. re@ can do whatever they want with my blessing. -- DE