Re: Intel x86 memory model question
- From: David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
- Date: Mon, 05 Sep 2005 21:21:12 GMT
Joe Seigh wrote:
David Hopwood wrote:Joe Seigh wrote:Alexander Terekhov wrote:
So where do you put the fence, then?
: processor 1 stores into X : processor 2 see the store by 1 into X and stores into Y : processor 3 loads from Y : processor 3 loads from X
Since this was my example I should clarify. It was meant to show that PC alone wasn't sufficient to guarantee that if processor 3 saw the store into Y by processor 2 that it would see the store into X by processor 1.
My understanding of the ia32 memory model is that you need a fence instruction between the loads by processor 3 and a fence between the load and store by processor 2 to make the guarantee work.
My understanding is that if the claimed problem exists at all, adding these fences won't fix it (as far as the model is concerned, possibly as opposed to implementation details of specific chips).
The architected memory model as opposed to the implemented one?
Yes, that's what I said.
"Despite the fact that Pentium 4, Intel Xeon, and P6 family
processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable
to future processors, it is recommended that operating systems provide
critical region and resource control constructs and API’s (application
program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of
memory in multiple-processor systems."
This is all perfectly sensible. "Future processors" from Intel are not necessarily ISA-compatible with x86 anyway. For example, you need to recompile to use long mode in EM64T. Also note that it doesn't say "future x86 processors". Maybe they were talking about Itanic.
Even if they weren't talking about IA-64 or a different mode, it's still a good idea to avoid dependencies on the memory model in *applications*, since it is more difficult to change all apps that have such dependencies than it is to change threading libraries in OS and language implementations. In fact OS/lang-impl maintainers half expect stuff to rot on new hardware, and hopefully remember what they depended on. Application maintainers generally don't (if they ever understood it in the first place). This is what I've been saying consistently.
Anyway, this issue doesn't have anything to do with what we were talking about, which is whether the current architected x86 model allows a particular behaviour.
That one? And what do people think the memory model that only "I/O, locking, and/or serializing instructions" can synchronize is?
You're overanalysing a fairly loosely worded recommendation.
-- David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx> .
- Follow-Ups:
- Re: Intel x86 memory model question
- From: Joe Seigh
- Re: Intel x86 memory model question
- References:
- Re: Intel x86 memory model question
- From: Andy Glew
- Re: Intel x86 memory model question
- From: Joe Seigh
- Re: Intel x86 memory model question
- From: Alexander Terekhov
- Re: Intel x86 memory model question
- From: Joe Seigh
- Re: Intel x86 memory model question
- From: Eric P.
- Re: Intel x86 memory model question
- From: Alexander Terekhov
- Re: Intel x86 memory model question
- From: Joe Seigh
- Re: Intel x86 memory model question
- From: David Hopwood
- Re: Intel x86 memory model question
- From: Joe Seigh
- Re: Intel x86 memory model question
- Prev by Date: Re: Intel x86 memory model question
- Next by Date: Re: Intel x86 memory model question
- Previous by thread: Re: Intel x86 memory model question
- Next by thread: Re: Intel x86 memory model question
- Index(es):
Relevant Pages
|
Loading