Date: Fri, 25 Sep 2009 06:26:37 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Fabio Checconi <fabio@freebsd.org> Cc: attilio@freebsd.org, hackers@freebsd.org Subject: Re: sx locks and memory barriers Message-ID: <1253877997.2031.2627.camel@balrog.2hip.net> In-Reply-To: <20090924224935.GW473@gandalf.sssup.it> References: <20090924224935.GW473@gandalf.sssup.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1253877997.2031.2627.camel>