From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 14 18:18:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E827E0D; Fri, 14 Feb 2014 18:18:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71C2116EC; Fri, 14 Feb 2014 18:18:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E401B9A3; Fri, 14 Feb 2014 13:18:50 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Debugging rw lock Date: Fri, 14 Feb 2014 12:59:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52FD32FF.70106@mu.org> <52FD91E2.4080903@freebsd.org> In-Reply-To: <52FD91E2.4080903@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402141259.15712.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 14 Feb 2014 13:18:50 -0500 (EST) Cc: hackers@freebsd.org, Alfred Perlstein , Vijay Singh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:18:51 -0000 On Thursday, February 13, 2014 10:47:46 pm Julian Elischer wrote: > On 2/14/14, 5:02 AM, Alfred Perlstein wrote: > > > > On 2/13/14, 12:59 PM, Vijay Singh wrote: > >> You're talking about instrumenting the code, right? But which > >> thread? I was > >> thinking of augmenting the rw lock to record the readers, but > >> wanted to > >> check if something is possible without instrumentation. > > > > If rw locks are implemented using low level atomics then you're > > going to make the very slow and have a LOT of work to do as opposed > > to just using a thread specific storage to implement it. You're > > better off just making use of the fact that only "curthread" can > > access the per-thread stack and just use that. Or at least that's > > how it works in my brain. > > maybe do it the other way around and count the read locks a thread > has.. then when there is a problem go see what they hold.. > (or add the ability to detail 10 locks each or something) We already do that. Vijay, you can look at td_rw_rlocks in each struct thread. You can at least ignore the threads with a count set to zero. The other option is to run with WITNESS enabled. You can then do 'show all locks' in ddb and you can see which thread owns the lock (and the file and line number where it acquired it) -- John Baldwin