Subj : Re: Three membar-related questions
To   : comp.programming.threads
From : SenderX
Date : Sat Feb 05 2005 12:19 am

>  - Some things I read claim that memory barriers are applicable only to
>    multiprocessor systems, because uniprocessor systems always appear to
>    execute in program order.  Other things I read claim that this is
>    untrue, that uniprocessors with pipelines and speculative fetches can
>    run into memory visibility problems, too, so memory visibility is an
>    issue even for uniprocessor programming.  Which is it?
>
>  - What's the situation wrt multicore processors?  From a memory
>    visibility point of view, are they multiprocessors (and hence in need
>    of memory barriers in their software) or uniprocessors (and, assuming
>    uniprocessors don't need memory barriers, not in need of them)?

Assume your running on a multi-processor system that has weak-order memory 
model. Think of Linux's read_barrier_depends(...)




>      On x86 processors up to P4, barriers are available, but not
>      necessary.  Intel has warned that this will change in the future.

A fence is necessary if a "critical-sequence" of loads, stores, and function 
calls simply cannot cope with the fact that a store followed by a load from 
"another location" can be reordered:


1: movl %eax, (%location_one)
2: movl (%location_two), %ecx


Instruction 2 could be executed before instruction 1's effects become 
visible.

.