From owner-freebsd-threads@FreeBSD.ORG Thu Apr 26 01:20:45 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 1D3BF106564A; Thu, 26 Apr 2012 01:20:45 +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 C6AF88FC0A; Thu, 26 Apr 2012 01:20:44 +0000 (UTC) Received: by obcni5 with SMTP id ni5so21264obc.13 for ; Wed, 25 Apr 2012 18:20:44 -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=WjzlvHMwpyiMQS/B6AkjFHglEnJU0EOnKxyxlD36AhE=; b=HmWEMEH2OovsMeEpM1anrapxCfxNYBTUlyJfAUP7iFTsCVxZb50AcHFFJvFZue4Y6S eGy6cderNpn+xJ73EnGAAhvTZ0hA7cE9plbelIl2FaZmle3t6z15MHXKRE76vZN07Nfx c/5wrmNAe4+dwXGgGMrsodZqZlJB5dPPn0PytsdoVW1Uyl1Y+6PMUM7smpkdahDp2fHK ljYg9XIyZWct8gz56blndS0bPAdaiw1Qu6c0IN6NRO8E3e7gtJll/fLlrNsnGybiMZhd 6C7qaJHvn2/n15yRR3sZVRu08t0f5AStbjAeoWXgs0aocgOCKyAZifKwEoYQFpLMQ6Sa zKXQ== MIME-Version: 1.0 Received: by 10.182.113.106 with SMTP id ix10mr6046003obb.26.1335403244475; Wed, 25 Apr 2012 18:20:44 -0700 (PDT) Received: by 10.60.125.135 with HTTP; Wed, 25 Apr 2012 18:20:44 -0700 (PDT) In-Reply-To: <201204251012.36754.jhb@freebsd.org> References: <20120423084120.GD76983@zxy.spb.ru> <20120425062627.GI2358@deviant.kiev.zoral.com.ua> <201204251012.36754.jhb@freebsd.org> Date: Thu, 26 Apr 2012 09:20:44 +0800 Message-ID: From: Fengwei yin To: John Baldwin 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: Thu, 26 Apr 2012 01:20:45 -0000 On Wed, Apr 25, 2012 at 10:12 PM, John Baldwin wrote: > On Wednesday, April 25, 2012 3:05:54 am Fengwei yin wrote: >> On Wed, Apr 25, 2012 at 2:26 PM, Konstantin Belousov >> wrote: >> > On Wed, Apr 25, 2012 at 11:25:40AM +0800, Fengwei yin wrote: >> >> On Wed, Apr 25, 2012 at 2:13 AM, Konstantin Belousov >> >> wrote: >> >> > On Tue, Apr 24, 2012 at 07:00:33PM +0100, Martin Simmons wrote: >> >> >> >>>>> On Tue, 24 Apr 2012 19:58:42 +0300, Konstantin Belousov said= : >> >> >> > >> >> >> > + >> >> >> > + =A0 /* >> >> >> > + =A0 =A0* Lock the spinlock used to protect __sglue list walk i= n >> >> >> > + =A0 =A0* __sfp(). =A0The __sfp() uses fp->_flags =3D=3D 0 test= as an >> >> >> > + =A0 =A0* indication of the unused FILE. >> >> >> > + =A0 =A0* >> >> >> > + =A0 =A0* Taking the lock prevents possible compiler or process= or >> >> >> > + =A0 =A0* reordering of the writes performed before the final _= flags >> >> >> > + =A0 =A0* cleanup, making sure that we are done with the FILE b= efore >> >> >> > + =A0 =A0* it is considered available. >> >> >> > + =A0 =A0*/ >> >> >> > + =A0 STDIO_THREAD_LOCK(); >> >> >> > =A0 =A0 fp->_flags =3D 0; =A0 =A0 =A0 =A0 /* Release this FILE f= or reuse. */ >> >> >> > + =A0 STDIO_THREAD_UNLOCK(); >> >> >> > =A0 =A0 FUNLOCKFILE(fp); >> >> >> > =A0 =A0 return (r); >> >> >> >> >> >> Is that assumption about reordering correct? =A0I.e. is FreeBSD's = spinlock a >> >> >> two-way barrier? >> >> >> >> >> >> It isn't unusual for the locking primitive to be a one-way barrier= , i.e. (from >> >> >> Linux kernel memory-barriers.txt) "Memory operations that occur be= fore a LOCK >> >> >> operation may appear to happen after it completes." =A0See also ac= q and rel in >> >> >> atomic(9). >> >> > Taking the lock prevents the __sfp from iterating the list until th= e >> >> > spinlock is released. Since release makes sure that all previous me= mory >> >> > operations become visible, the acquire in the spinlock lock provide= s >> >> > the neccesary guarentee. >> >> >> >> IMHO, the lock to me is too heavy here. What about this patch? >> >> >> >> NOTE: patch just show thoughts. I didn't even check build checking. >> > Yes, it might be correct. But FreeBSD does prefer the acq/rel barriers >> > over the rmb/wmb. >> > >> >> There is no stand alone acq/rel APIs (Sorry, as new guy to FreeBSD, >> don't know too much APIs). =A0They are bound to atomic operations. >> And yes, atomic_acq/rel should work also. > > Yes, you would want to use atomic_store_rel() or some such. =A0Often doin= g > so is much clearer than stand-alone membar's as it indicates which write > has special ordering. > Thanks a lot for clarification. >> > Also, the lock is not that heavy right there, and the committed patch >> > provides mostly zero overhead for non-threaded case. >> >> But lock could introduced contention in SMP case which could be avoid >> with rmb/wmb. > > Seriously, if you are using stdio, you've already given up on performance > enough to not care about contention for fclose() vs fopen(). > This makes sense. > -- > John Baldwin