Subj : Re: Three membar-related questions
To   : comp.programming.threads
From : Joseph Seigh
Date : Fri Feb 04 2005 01:19 pm

On Fri, 4 Feb 2005 09:47:15 -0800, Scott Meyers <Usenet@aristeia.com> wrote:

> There are three issues I'm still unclear about:
>
>   - 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?

The memory accesses can be out of order but they always appear in order
to the processor that executed them and you have only one processor.
However other things can detect that they're out of order such as
stores and fetches from memory mapped to i/o devices, ie. the i/o
address range.

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

You should assume they're the same as multiprocessors.  Even if memory
appeared to be in total store order to all the cores in the same cpu,
and that's a platform dependent property, you could have more than one cpu.

>
>   - I wrote up the following summary of the situation wrt memory barriers
>     on x86, but I'm not sure it's true.  I'd appreciate comments on whether
>     this is accurate:
>
>       On x86 processors up to P4, barriers are available, but not
>       necessary.  Intel has warned that this will change in the future.

I know stores are in order but I've heard some say the loads are also but
yes Intel has warned on that and unless you want to write code that queries
the processor model, you should assume that.  Though there's probably so
much code that assumes total store order that Intel would be taking a huge
risk making stores out of order.





-- 
Joe Seigh

.