Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 17 Nov 2006 05:09:50 -0600
Date: Fri, 17 Nov 2006 06:12:19 -0500
From: Joe Seigh <jseigh...@xemaps.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.arch,comp.programming.threads
Subject: Re: x86 Sequential Consistency
References: <4s2rp8Ftne37U1@mid.individual.net>
In-Reply-To: <4s2rp8Ftne37U1@mid.individual.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <gpKdnWXsppDjBcDYnZ2dnUVZ_oKdnZ2d@comcast.com>
Lines: 45
NNTP-Posting-Host: 24.60.62.236
X-Trace: sv3-LGO1ocuccnCF8ZHPNxn0KUM1a1jxrZRnCzRm+4Z605c3ossTBi/7kz4bdfZhrASoL0mbMoVHNR/b2wY!VUOn8mrHmBXVoA4Dzzqe+cAkRDu1ptx6Ck7xnxp5xUPnbGtSnMwfipD8TiY1EojpecjfL8yhheUQ!RzJsU1hf
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: d...@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.32

Adam Warner wrote:
> Hi all,
> 
> In my prior posts to comp.programming.threads [note new crosspost to
> comp.arch] I described an algorithm where CPU A makes a number of memory
> writes before writing to a memory location that acts as a flag. When CPU B
> reads the changed flag (it's theoretically irrelevant whether the change
> takes a nanosecond or a day to propagate to CPU B) all the writes that
> were made by CPU A prior to CPU A writing to the memory flag must be
> correctly readable by CPU B. A sequentially consistent architecture
> satisfies this property.
> 
> Historically the shared memory IA-32 multiprocessor architecture has been
> sequentially consistent:
[...]
> 
> The fear initiated by Intel and co. that programmers must use special
> serializing and locking operations to ensure future x86 compatibility does
> not have to be amplified by the wider community. Let's assume future
> changes to the x86 memory model do break existing programs that rely upon
> a sequentially consistent architecture. To ensure old programs don't fail
> in potentially mysterious ways an operating system could check all
> executables for the export of a symbol indicating awareness of the new
> memory model (and otherwise defaulting to program termination). Whatever
> the marketing department called the new architecture they wouldn't be able
> to weasel around such a stark reminder of binary incompatibility.
> 
> I am happy to conform to the memory model of the architecture I am
> compiling for. I just need to confirm what it realistically is.
> 

I think Intel is in the pretending the problem does not exist mode until
they can figure out what to do about it.  About the only thing you can
do is put an abstraction layer in place to insulate your programs from
any memory model changes.  Usually this is just a bunch of memory barrier
and atomic access macros to give you the guarantees that you need.  You
can take a look at how the Linux kernel does it or look at atomic_ops
in http://www.hpl.hp.com/research/linux/qprof/


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.