About the memory barrier in BSD libc

[Konstantin Belousov]

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:
> > 
> > +
> > +	/*
> > +	 * 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).
Taking the lock prevents the __sfp from iterating the list until the
spinlock is released. Since release makes sure that all previous memory
operations become visible, the acquire in the spinlock lock provides
the neccesary guarentee.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20120424/b5af78a7/attachment.pgp