From owner-freebsd-hackers@FreeBSD.ORG Wed May 4 05:26:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C79116A4CE for ; Wed, 4 May 2005 05:26:23 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3ACB43D6A for ; Wed, 4 May 2005 05:26:22 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id j445QBOZ036150; Tue, 3 May 2005 22:26:11 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <42785CF3.20009@freebsd.org> Date: Tue, 03 May 2005 22:26:11 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Giacomoni References: <200504261456.52070.jhb@FreeBSD.org> In-Reply-To: <200504261456.52070.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: what goes wrong with barrier free atomic_load/store? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 05:26:23 -0000 > On Wednesday 20 April 2005 04:39 pm, John Giacomoni wrote: > >>can someone give me an example of a situation where one needs to use >>memory barriers to ensure "correctness" when doing writes as above? One basic example: struct foo *p = malloc(sizeof(struct foo)); // Step 1 p->bar = 0; // Step 2 atomic(global_p = p); // Step 3 This is a pretty common idiom: Allocate a new data structure, initialize it, then assign the pointer to a shared global value so that the fully-initialized structure becomes visible all at once. Many people miss an important detail: A barrier is needed just before the final pointer assignment. Otherwise, the pointer might reach shared memory (Step 3) before the initialization in Step 2 happens. (This can happen because of compiler reordering or processor write caching.) Variations of this plagued the early attempts to correctly define Java's threading primitives. (It was possible to crash a lot of early JVMs by creating new objects in one thread and accessing them in another; every now and then the accessing thread would see an uninitialized vtable and crash the entire JVM.) Tim Kientzle