From owner-freebsd-current@FreeBSD.ORG Wed May 21 05:38:21 2003 Return-Path: <owner-freebsd-current@FreeBSD.ORG> 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 A3ABB37B409 for <current@FreeBSD.org>; Wed, 21 May 2003 05:38:21 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AF6F43F85 for <current@FreeBSD.org>; Wed, 21 May 2003 05:38:20 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18891 invoked from network); 21 May 2003 12:38:19 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>)encrypted SMTP for <rwatson@FreeBSD.org>; 21 May 2003 12:38:19 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h4LCcHp0057539; Wed, 21 May 2003 08:38:18 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: <XFMail.20030521083829.jhb@FreeBSD.org> 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: <3ECB023B.40666E3D@mindspring.com> Date: Wed, 21 May 2003 08:38:29 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> cc: Robert Watson <rwatson@FreeBSD.org> 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 <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current> List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 21 May 2003 12:38:22 -0000 On 21-May-2003 Terry Lambert wrote: > John Baldwin wrote: >> >> According to chapter 12 of the "Go Solo 2" book, this is a bogus thing >> >> to do. Callers are required to take a critical section over the calls >> >> to the dl* functions because the dlerror() function uses a static buffer >> >> that can be overwritten in a multi-threaded environment. >> > >> > Sadly, that insight doesn't seem to have influenced the development >> > practices of a number of major application vendors :-(. >> >> As Peter has mentioned before, simply locking calls to dlopen() in the >> application is not sufficient since every time you have to resolve a >> symbol when doing a call to a function for the first time, you hit the >> same data structures and need the locks in those cases as well. Assuming >> I recalled all that correctly. > > 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. > 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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/