what goes wrong with barrier free atomic_load/store?

[John Baldwin]

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
> 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

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