From owner-freebsd-threads@FreeBSD.ORG Mon Apr 23 11:44:35 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45EEC106566B for ; Mon, 23 Apr 2012 11:44:35 +0000 (UTC) (envelope-from yfw.bsd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 05F4E8FC0C for ; Mon, 23 Apr 2012 11:44:34 +0000 (UTC) Received: by obqv19 with SMTP id v19so17879749obq.13 for ; Mon, 23 Apr 2012 04:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Yr+TqV8odryk8/PaHmCM25vl1xvoz8pVTnyjKvau+AM=; b=x1wqzy6zlbR3Tb+Q0ZqGwHG9iXBvELdXp43COKC/bWKEmOjzp/5prQb4dGwvvl07+E uvcHqZchqJl2i58+OeNn/LBFhPFB/zwwyt2bI4o6Uwm49jPZBdohF8K/1s7UDZ+awo2w RnHDFU0Ul+XddxGMIP0AlqQwyrjfr/ALvJ4i7AyqqlJUEbOya4PfILSJE5gkUPzvkvWM HxFsN9JkZR2I1FaE2s6rvCglIh3DBPP7SBpZqRSVOrkpsGVNaQTbAjFYLGg+HXIACC/m JAtsx87AYeXUovGNyAdkHGpXJZMhqMBgyMrhSz3Bq+AuisH+8poTCk9p9SXlh74DCN0n 9o+g== MIME-Version: 1.0 Received: by 10.60.29.39 with SMTP id g7mr3006914oeh.6.1335181474441; Mon, 23 Apr 2012 04:44:34 -0700 (PDT) Received: by 10.60.125.135 with HTTP; Mon, 23 Apr 2012 04:44:34 -0700 (PDT) In-Reply-To: <20120423113838.GT32749@zxy.spb.ru> References: <20120423084120.GD76983@zxy.spb.ru> <20120423094043.GS32749@zxy.spb.ru> <20120423113838.GT32749@zxy.spb.ru> Date: Mon, 23 Apr 2012 19:44:34 +0800 Message-ID: From: Fengwei yin To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jack.ren@intel.com, freebsd-threads@freebsd.org Subject: Re: About the memory barrier in BSD libc X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:44:35 -0000 On Mon, Apr 23, 2012 at 7:38 PM, Slawa Olhovchenkov wrote: > On Mon, Apr 23, 2012 at 07:26:54PM +0800, Fengwei yin wrote: > >> On Mon, Apr 23, 2012 at 5:40 PM, Slawa Olhovchenkov wro= te: >> > On Mon, Apr 23, 2012 at 05:32:24PM +0800, Fengwei yin wrote: >> > >> >> On Mon, Apr 23, 2012 at 4:41 PM, Slawa Olhovchenkov = wrote: >> >> > On Mon, Apr 23, 2012 at 02:56:03PM +0800, Fengwei yin wrote: >> >> > >> >> >> Hi list, >> >> >> If this is not correct question on the list, please let me know an= d >> >> >> sorry for noise. >> >> >> >> >> >> I have a question regarding the BSD libc for SMP arch. I didn't se= e >> >> >> memory barrier used in libc. >> >> >> How can we make sure it's safe on SMP arch? >> >> > >> >> > /usr/include/machine/atomic.h: >> >> > >> >> > #define mb() =A0 =A0__asm __volatile("lock; addl $0,(%%esp)" : : : = "memory") >> >> > #define wmb() =A0 __asm __volatile("lock; addl $0,(%%esp)" : : : "m= emory") >> >> > #define rmb() =A0 __asm __volatile("lock; addl $0,(%%esp)" : : : "m= emory") >> >> > >> >> >> >> Thanks for the information. But it looks no body use it in libc. >> > >> > I think no body in libc need memory barrier: libc don't work with >> > peripheral, for atomic opertions used different macros. >> >> If we check the usage of __sinit(), it is a typical singleton pattern wh= ich >> needs memory barrier to make sure no potential SMP issue. >> >> Or did I miss something here? > > What architecture with cache incoherency and FreeBSD support? I suppose it's not related with cache inchoherency (I could be wrong). It's related with reorder of instruction by CPU. Here is the link talking about why need memory barrier for singleton: http://www.oaklib.org/docs/oak/singleton.html x86 has strict memory model and may not suffer this kind of issue. But ARM need to take care of it IMHO. Regards Yin, Fengwei