From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 17:32:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66DF616A527; Wed, 13 Dec 2006 17:32:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8506543E1B; Wed, 13 Dec 2006 17:29:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBDHUTsF030233; Wed, 13 Dec 2006 12:30:39 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Evans Date: Wed, 13 Dec 2006 12:26:46 -0500 User-Agent: KMail/1.9.1 References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <20061213133411.S1136@delplex.bde.org> In-Reply-To: <20061213133411.S1136@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612131226.48087.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 13 Dec 2006 12:30:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2324/Wed Dec 13 11:04:08 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Mailman-Approved-At: Wed, 13 Dec 2006 17:44:36 +0000 Cc: freebsd-stable@freebsd.org, Suleiman Souhlal , Attilio Rao , freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov , tegge@freebsd.org Subject: Re: kqueue LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 17:32:11 -0000 On Tuesday 12 December 2006 21:48, Bruce Evans wrote: > > Memory barriers just specify ordering, they don't ensure a cache flush so > > another CPU reads up to date values. You can use memory barriers in > > conjunction with atomic operations on a variable to ensure that you can > > safely read other variables (which is what locks do). For example, in this > > I thought that the acquire/release variants of atomic ops guarantee > this. They seem to be documented to do this, while mutexes don't seem > to be documented to do this. The MI (?) implementation of mutexes > depends on atomic_cmpset_{acq,rel}_ptr() doing this. The acq/rel just specify ordering. As Attilio mentioned, we assume that the atomic_cmpset() that sets the contested flag will fail while racing with another CPU (even if the CPU can't see the new value, as long as it fails and keeps spinning mutexes will still work). The 'rel' barrier on CPU A when releasing a lock forces all the other writes to be posted (and eventually become "visible") to other CPUs before the write that releases the lock. The 'acq' barrier on CPU B when acquiring the lock forces the CPU to not reorder any reads before it acquires the lock, so this makes you not read any data until you have the lock. Thus, once CPU B has waited long enough to "see" the write from A to release the lock, we know that 1) it can also "see" all the other writes from that CPU that the lock protected, and 2) B hasn't tried to read any of them yet so it shouldn't have any stale values in registers. None of this requires the OS to do a cache flush. (If you have an SMP system where the cache can still hold stale values after another CPU updates values in memory where it is "visible" to the CPU acquiring the lock, then _acq might need to flush the cache, but that would be a property of that architecture. However, even that would not require cache flushes so long as the stale values were evicted from the cache such that they honor the memory barrier and you don't see the new value of the lock until you see the new values of the earlier data.) -- John Baldwin