From owner-freebsd-current@FreeBSD.ORG Thu May 22 09:33:50 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED38637B401 for ; Thu, 22 May 2003 09:33:50 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69DDF43FBF for ; Thu, 22 May 2003 09:33:49 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14215 invoked from network); 22 May 2003 16:33:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 22 May 2003 16:33:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h4MGXkp0061367; Thu, 22 May 2003 12:33:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3ECCECE6.E1D7E8D0@mindspring.com> Date: Thu, 22 May 2003 12:33:58 -0400 (EDT) From: John Baldwin To: Terry Lambert cc: re@FreeBSD.org cc: Robert Watson cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:33:51 -0000 On 22-May-2003 Terry Lambert wrote: > John Baldwin wrote: >> > That's an order of operations problem, not a locking problem. Just >> > like a lot of the simple queue.h structures that are unnecessarily >> > being locked around modificiations because the macros aren't being >> > rewritten to make the updates atomic. >> >> Unless you plan to use expensive atomic operations and memory barriers >> to ensure in-order operation pessimizing all the lists that don't need >> protecting you are going to need to protect shared lists. Please do >> remember that writes from one CPU are not guaranteed to be visible to >> other CPU's in program order. > > You don't care if another CPU re-does the work, so long as it > re-does it atomically. That makes it thread safe without the > introduction of locks. We aren't talking about re-doing the work, we're talking about one CPU trying to walk the list while it's an inconsistent state and walking off into the weeds through a stale pointer. I.e, CPU 0 removes an item from the list while CPU 1 is walking over that item. Duh. > Introducing locks introduces "expensive atomic operations and memory > barriers"; redoing it introduces an extra function call of overhead > that doesn't matter and is less expensive. Since the locks are only used on shared lists, they aren't present on lists that don't need protecting, whereas doing them in the queue macros itself would pessimize all lists, unless you want to have a runtime check and function call. Also, one thing you clearly have not noticed is that locks that cover lists usually also cover several other members of a related data structure, so you often need the lock anyways while you manipulate several data members of a structure. >> > It's a really bad idea to imply a locking policy in something as >> > fundamental as the runtime linker code, unless you expect to be >> > able to replace the primitives at compile/link/runtime at some >> > point. >> >> Unless I'm mistaken we aren't the first set of folks to add locking >> to the runtime linker. I'm sure that there is already a suitable >> bikeshed over this on the threads@ list though. > > Just because your friend jumped off a cliff... So what is your magic solution for making rtld thread-safe when looking up unresolved symbols on first reference? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/