From owner-freebsd-current@FreeBSD.ORG Wed Dec 13 02:48:54 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 7802216A47C; Wed, 13 Dec 2006 02:48:54 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D255143CA2; Wed, 13 Dec 2006 02:47:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 7F5406E04A; Wed, 13 Dec 2006 13:48:24 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 1FB2C8C2C; Wed, 13 Dec 2006 13:48:24 +1100 (EST) Date: Wed, 13 Dec 2006 13:48:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200612121412.13551.jhb@freebsd.org> Message-ID: <20061213133411.S1136@delplex.bde.org> References: <456950AF.3090308@sh.cvut.cz> <3bbf2fe10612120643n6b4ad850oc857be46c48505cc@mail.gmail.com> <457EF835.2020705@FreeBSD.org> <200612121412.13551.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 13 Dec 2006 04:38:53 +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 02:48:54 -0000 On Tue, 12 Dec 2006, John Baldwin wrote: > On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote: >> Why is memory barrier usage not encouraged? As you said, they can be used to >> reduce the number of atomic (LOCKed) operations, in some cases. >> ... >> Admittedly, they are harder to use than atomic operations, but it might >> still worth having something similar. How would MI code know when using memory barriers is good? This is already hard to know for atomic ops -- if there would more than a couple of atomic ops then it is probably better to use 1 mutex lock/unlock and no atomic ops, since this reduces the total number of atomic ops in most cases, but it is hard for MI code to know how many "a couple" is. (This also depends on the SMP option -- without SMP, locking is automatic so atomic ops are very fast but mutexes are still slow since they do a lot more than an atomic op.) > 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. Bruc