From owner-freebsd-stable@FreeBSD.ORG Thu May 12 13:13:48 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 472D516A4CE; Thu, 12 May 2005 13:13:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49E8043D68; Thu, 12 May 2005 13:13:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] ([168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4CDHu7C046953; Thu, 12 May 2005 07:17:57 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4283565B.6060303@samsco.org> Date: Thu, 12 May 2005 07:12:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org 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 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 13:13:48 -0000 Daniel Eischen wrote: > 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. > Yes, the check for the cross-linked threads libraries is still quite useful. However, we gave a general policy of turning off most other debugging and invariants tools for production releases. A good example is the malloc debugging options that are on in HEAD and off in RELENG_5. Would we be able to reach a compromise similar to that? Scott