what goes wrong with barrier free atomic_load/store?

[John Giacomoni]

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 
processor
  * 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 
mechanism
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 
the
purpose of only having atomic_load/atomic_store wrappers with memory 
barriers.

I saw a brief discussion where someone proposed barrier free load/store 
but
don't think I saw any resolution.

thanks,

John G


--

John.Giacomoni at colorado.edu
University of Colorado at Boulder
Department of Computer Science
Engineering Center, ECCS 121
430 UCB
Boulder, CO 80303-0430
USA