From owner-freebsd-threads@FreeBSD.ORG Fri Apr 18 01:02:41 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D57537B401; Fri, 18 Apr 2003 01:02:41 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E8A43F3F; Fri, 18 Apr 2003 01:02:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0088.cvx40-bradley.dialup.earthlink.net ([216.244.42.88] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196QpS-0003ks-00; Fri, 18 Apr 2003 01:02:39 -0700 Message-ID: <3E9FB0D0.57CF9343@mindspring.com> Date: Fri, 18 Apr 2003 01:01:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c4b46d059d7a7576d2741988809111a6667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 08:02:41 -0000 Daniel Eischen wrote: > Ahh, OK. There aren't that many locks used by the library. > We can probably come up with something that does what you > want. I don't think it's an issue (IMO -- see other post). However, if you guys are really concerned with this (in the kernel, too, if it comes to that), then add a "parent_lock" parameter to the mutex creation routine, and set it. Then, if you think there is an issue, you can instrument it by simply checking that the lock is held by the same entity all the way to the root, when you acquire a lock. This beats the witness approach all to heck for diagnostics: you can collect/check all the information you want about the locking entities (thread id, process id, program counter at which the lock was asserted, whatever). Also, at some point, this structure would allow you to have both intention mode locking ("SIX" locks), and allow you to lock partial lists instead of complete lists, to reduce overall contention (e.g. divide a list into 8 parts, one lock per part, create another lock parent, assign it as the parent of all 8 locks, and then get a SIX lock on the parent when you are planning on traversing the list, and then rotor through an X lock on all the inferior locks as you traverse each range -- yields a concurrency of 8, with 1/8 the stall length for write locks). -- Terry