Date: Wed, 17 Sep 2003 19:34:58 -0000 From: John Baldwin <jhb@FreeBSD.org> To: Alan Cox <alc@cs.rice.edu> Cc: smp@freebsd.org Subject: Re: atomicity of unlocked reads Message-ID: <XFMail.20030917153453.jhb@FreeBSD.org> In-Reply-To: <20030917182237.GM12711@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-Sep-2003 Alan Cox wrote: > On Wed, Sep 17, 2003 at 10:50:58AM -0700, Frank Mayhar wrote: >> John Baldwin wrote: >> > I think you can assume that the read will be atomic. I don't think FreeBSD >> > would work very well on a machine where aligned pointer reads/writes weren't >> > atomic. >> >> I dunno, I tend to think that making such assumptions may well come back to >> bite me in the ass when I least expect it. In such situation, I invariably >> use some kind of "atomic_xxx_load/store" primitive that does the job safely >> and in a machine-dependent way while hiding the details from the MI code. >> > > Indeed. Atomicity of the read is not the only issue. Unless I > misunderstood, Bruce is proposing to perform an unsynchronized read of > a location that is updated by a different processor. This > unsynchronized read is to obtain a pointer. In weaker memory > consistency models (than that of the x86), there is no guarantee that > the data that the pointer refers to will be consistent. In other > words, updates to the data that the pointer refers to may not have > completed, even though the update to the memory location containing > the pointer has completed. > > This is what an "acquire load" is for. Roughly speaking, it should > guarantee that any updates prior to a corresponding "release store" > (by a different processor) will be seen. > > If we don't use "acquire loads" and "release stores" under such > circumstances, the poor guy who ports FreeBSD to a processor that, for > example, reorders loads, will be an unhappy camper. No, that is not what an acquire load is for. Memory barriers only affect the order of memory operations on the current processor, they have no bearing on other processors and don't provide any direct synchronization with other processors. Instead, if I have an acquire barrier, then the processor is not allowed to re-order any later reads or writes before the marked read. Note that earlier reads or writes can be re-ordered after the marked read. A release barrier is the opposite in that prior reads/writes must be completed prior to the marked write, but later reads/writes may be re-ordered before the marked write. Bruce explicitly said that if he reads a stale value, that is ok, so the membars don't do anything for him. If he is worried about stale data, then he needs a lock, not just atomic operations. The way that a lock works is that when we try to acquire a lock, we use an acquire barrier. This means that later reads/writes in the instruction stream won't be re-ordered before the lock acquire. When we release the lock we use a release barrier to ensure that any modifications made while holding the lock will be visible before the write to release the lock is visible. Thus, you can have CPU A acquire lock L, make a few writes, and then release lock L. If CPU B tries to acquire lock L after A has released it but before the write releasing the lock is visible to B, B will end up spinning (see the MTX_CONTESTED flag in the mutex code) until that write is visible (unless another thread has already blocked on this lock, in which case B will just block right away) until the write releasing L is visible to B. B can then acquire lock L. Since it had to wait for L's release write to be visible, this means that all the writes A performed are now visible to B, and thus B will not read stale data. Thus, memory barriers don't actually enforce any synchronization, they just give you a tool that can be used in conjunction with a memory location to construct a lock primitive that enforces sychronization. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030917153453.jhb>