From owner-freebsd-current@FreeBSD.ORG Thu May 22 08:30:54 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 230C537B401; Thu, 22 May 2003 08:30:54 -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 5EF5A43FA3; Thu, 22 May 2003 08:30:53 -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 19Is1r-0001Rx-00; Thu, 22 May 2003 08:30:52 -0700 Message-ID: <3ECCECE6.E1D7E8D0@mindspring.com> Date: Thu, 22 May 2003 08:29:42 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44cd15d84a27b0bd731d76393a193caa5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Robert Watson cc: re@FreeBSD.org 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 15:30:54 -0000 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. 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. > > 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... -- Terry