sx locks and memory barriers

[Robert Noland]

On Fri, 2009-09-25 at 00:49 +0200, Fabio Checconi wrote:
> Hi all,
>   looking at sys/sx.h I have some troubles understanding this comment:
> 
>  * A note about memory barriers.  Exclusive locks need to use the same
>  * memory barriers as mutexes: _acq when acquiring an exclusive lock
>  * and _rel when releasing an exclusive lock.  On the other side,
>  * shared lock needs to use an _acq barrier when acquiring the lock
>  * but, since they don't update any locked data, no memory barrier is
>  * needed when releasing a shared lock.
> 
> In particular, I'm not understanding what prevents the following sequence
> from happening:
> 
> CPU A					CPU B
> 
> sx_slock(&data->lock);
> 
> sx_sunlock(&data->lock);
> 
> /* reordered after the unlock
>    by the cpu */
> if (data->buffer)
> 					sx_xlock(&data->lock);
> 					free(data->buffer);
> 					data->buffer = NULL;
> 					sx_xunlock(&data->lock);
> 
> 	a = *data->buffer;
> 
> IOW, even if readers do not modify the data protected by the lock,
> without a release barrier a memory access may leak past the unlock (as
> the cpu won't notice any dependency between the unlock and the fetch,
> feeling free to reorder them), thus potentially racing with an exclusive
> writer accessing the data.

Maybe I am missing something suttle, but shouldn't the shared lock be
held for all data access if you want to guarantee sanity?  Meaning, if
you are accessing data->* without any locks held, all bets are off.

robert.

> On architectures where atomic ops serialize memory accesses this would
> never happen, otherwise the sequence above seems possible; am I missing
> something?
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD