About the memory barrier in BSD libc
kostikbel at gmail.com
Tue Apr 24 18:13:09 UTC 2012
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
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
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20120424/b5af78a7/attachment.pgp
More information about the freebsd-threads