From owner-freebsd-alpha Sat Dec 16 10:42:33 2000 From owner-freebsd-alpha@FreeBSD.ORG Sat Dec 16 10:42:31 2000 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 1DA8537B400 for ; Sat, 16 Dec 2000 10:42:31 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBGIgEE60055; Sat, 16 Dec 2000 10:42:14 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBGIfOc62489; Sat, 16 Dec 2000 10:41:24 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 16 Dec 2000 10:41:24 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Subject: RE: mb and wmb in atomic_ Cc: Bernd Walter , freebsd-alpha@FreeBSD.org Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Also, note that in FreeBSD, >> we have specific variants of atomic operations that include memory barriers >> (see the atomic(9) manpage in -current). If the actual atomicity of the >> operation doesn't need the mb, they should be removed. > > Atomicity seems here for both Alpha and i386. > > About Alpha, I doubt that using wmb() is a good idea, given that its does > not guarantee ordering of memory-like with respect to non memory-like and > this may lead to incorrect assumption from programmer when the both kinds > of memory are used (device drivers for example). From src/sys/alpha/include/alpha_cpu.h: static __inline void alpha_wmb(void) { /* * XXX dfr: NetBSD originally had mb instead of wmb for * alpha_wmb(). I'm not sure why so I'm leaving it alone. I * think it should be safe to use wmb though. */ __asm__ __volatile__ ("mb"); } > About i386 I donnot seem to see the promised read barrier for the > atomic_load_acq_X() primitives. Note that I also donnot see where such > primitive might be useful. :-) > Anyway, they seems wrong to me given that Pentia II and above may reorder > LOADs and LOADs against STOREs. We are only guaranteed STOREs to be > carried out to system BUS in processor order when cachable is involved, > and hitting non-cachable to insert implicit barriers. I'll have to look at this next week. So far only atomic_store_rel() has been used for the mutex operations. It could be that I need to change those to use lock'd cmpxchgl's in order to enforce ordering. > Gérard. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message