From owner-freebsd-smp Mon Dec 11 7:48:44 2000 From owner-freebsd-smp@FreeBSD.ORG Mon Dec 11 07:48:40 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id A9BCD37B400 for ; Mon, 11 Dec 2000 07:48:39 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA19232; Mon, 11 Dec 2000 07:48:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBBFmS619772; Mon, 11 Dec 2000 07:48:28 -0800 X-Virus-Scanned: Mon, 11 Dec 2000 07:48:28 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from brakescr.iprg.nokia.com (205.226.1.186, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd2XRk8Y; Mon, 11 Dec 2000 07:41:38 PST Sender: michaelw@IPRG.nokia.com Message-ID: <3A34F5B4.10A27571@iprg.nokia.com> Date: Mon, 11 Dec 2000 07:41:41 -0800 From: Michael Glenn Williams Organization: NOKIA X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Arun Sharma Cc: Chuck Paterson , smp@FreeBSD.ORG Subject: Re: Userland atomic assignments References: <200012091602.eB9G2UH06249@berserker.bsdi.com> <3A318757.4040108@sharmas.dhs.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There are also sometimes issues if the assignment is to code. The interaction of the caches and the memory model in force can be hard to keep clear. Userland sharing memory locations between threads (same address space & cache footprint) or processes (shmem/mmap type stuff) have things like pagefaults of course, but won't fetch something partially written from memory. Even if an I/O device is updating the memory location this has to be preserved. Even if the architecture permits wierd alignments of "atomic sized writes" it has to enforce this. Moving to a relaxed memory model has been difficult because all the ABI and DDI/DKI type issues of coordination and backwards compatibility get in the way. If a new processor architecture came about that had reason to support SMP designs and no legacy drivers or application binaries, they could do an RMO. Mike Arun Sharma wrote: > Chuck Paterson wrote: > > > } > > }However, the complexity comes from memory ordering issues. All of x86 boxes > > }ensure sequential consistency. > > } > > > > Sequenctial consistency from a single processor, which may well > > be what you meant. > > Actually, what I wrote in my previous mail wasn't completely accurate > about sequential > consistency. (c == d) => (a == b) basically means writes happen in program > order as you say above. > > > Writes from different processors to different cache lines are not > > ordered with respect to one another. Also writes from one processor > > are not at all ordered with respect to reads from another processor. > > > > What is guaranteed is that writes from a single processor will be > > ordered with respect to one another as viewed from any processor. > > What sequential consistency guarantees is that writes as seen from > some other processor would make sense for _some_ arbitrary intermixing > of writes from other processors. > > A more formal definition: > > http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212962,00.html > -Arun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message