About the memory barrier in BSD libc

[Martin Simmons]

>>>>> 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