Date: Tue, 24 Apr 2012 19:00:33 +0100 From: Martin Simmons <martin@lispworks.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: jack.ren@intel.com, freebsd-threads@freebsd.org Subject: Re: About the memory barrier in BSD libc Message-ID: <201204241800.q3OI0X89007384@higson.cam.lispworks.com> In-Reply-To: <20120424165842.GZ2358@deviant.kiev.zoral.com.ua> (message from Konstantin Belousov on Tue, 24 Apr 2012 19:58:42 %2B0300) References: <20120423084120.GD76983@zxy.spb.ru> <201204241343.q3ODhe2C032683@higson.cam.lispworks.com> <20120424140348.GY2358@deviant.kiev.zoral.com.ua> <201204241110.14017.jhb@freebsd.org> <20120424165842.GZ2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Tue, 24 Apr 2012 19:58:42 +0300, Konstantin Belousov said: > > + > + /* > + * Lock the spinlock used to protect __sglue list walk in > + * __sfp(). The __sfp() uses fp->_flags == 0 test as an > + * indication of the unused FILE. > + * > + * Taking the lock prevents possible compiler or processor > + * reordering of the writes performed before the final _flags > + * cleanup, making sure that we are done with the FILE before > + * it is considered available. > + */ > + STDIO_THREAD_LOCK(); > fp->_flags = 0; /* Release this FILE for reuse. */ > + STDIO_THREAD_UNLOCK(); > FUNLOCKFILE(fp); > return (r); Is that assumption about reordering correct? I.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 before a LOCK operation may appear to happen after it completes." See also acq and rel in atomic(9). __Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204241800.q3OI0X89007384>