From owner-freebsd-current@FreeBSD.ORG Thu May 22 09:51:49 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 B7CBA37B401; Thu, 22 May 2003 09:51:49 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA7643F3F; Thu, 22 May 2003 09:51:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ItI9-0004Ti-00; Thu, 22 May 2003 09:51:46 -0700 Message-ID: <3ECCFFD8.74A284C7@mindspring.com> Date: Thu, 22 May 2003 09:50:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4556c346d673baab1d9f25bfad9e88094667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c 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:51:50 -0000 John Baldwin wrote: > On 22-May-2003 Terry Lambert wrote: > > 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. A singly linked list can be maintained in a consistent state at all times, so long as pointer updates are atomic to a CPU. As I said before, this is an order of operation problem, not a locking problem. > > 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. These aren't list locks, these are locks on data structures containing lists. That's a very different thing. Are you trying to claim here that I can't get atomic pointer updates? > > 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? Change the order of operation. Basic database theory: o write new record o atomically update index to point from old record to new record o remove old record No matter how many time you reenter this, you end up with a consistent view. You don't have to worry about multiple updates in this case, because all updates are identical; it's not like you are contending to point a symbol one place, and some other CPU is contending to point it another; you are *both* trying to point it to the *same* place. So if you start pointing for you and someone else starts pointing for them, as long as the pointer points to *either* the "repoint thunk" *OR* "the right place", atomically, you don't really give a damn if you update it out from under somone, or they update it out from under you: it gets the same *right* value before it is used. -- Terry