what goes wrong with barrier free atomic_load/store?
jhb at FreeBSD.org
Tue Apr 26 12:44:43 PDT 2005
On Wednesday 20 April 2005 04:39 pm, John Giacomoni wrote:
> in reading /src/sys/i386/include/atomic.h
> I found this comment and I'm having trouble understanding what the
> problem being
> referred to below is.
> * We assume that a = b will do atomic loads and stores. However, on a
> * PentiumPro or higher, reads may pass writes, so for that case we have
> * to use a serializing instruction (i.e. with LOCK) to do the load in
> * SMP kernels. For UP kernels, however, the cache of the single
> * is always consistent, so we don't need any memory barriers.
> can someone give me an example of a situation where one needs to use
> memory barriers to ensure "correctness" when doing writes as above?
> the examples I can come up with seem to boil down to requiring locks
> or accepting stale values, given that without a synchronization
> one shouldn't expect two processes to act in any specific order.
> In my case I can accept reading a stale value so I'm not understanding
> purpose of only having atomic_load/atomic_store wrappers with memory
> I saw a brief discussion where someone proposed barrier free load/store
> don't think I saw any resolution.
> John G
We use atomic_store_rel() as part of implementing mutexes.
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-hackers