From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 08:52:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD8D16A41F for ; Thu, 12 Jan 2006 08:52:40 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BE843D46 for ; Thu, 12 Jan 2006 08:52:39 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail02.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0C8qcNl020805 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Jan 2006 19:52:38 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id k0C8qbHh064424 for ; Thu, 12 Jan 2006 19:52:38 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id k0C8qb0H064423 for freebsd-hackers@freebsd.org; Thu, 12 Jan 2006 19:52:37 +1100 (EST) (envelope-from pjeremy) Date: Thu, 12 Jan 2006 19:52:37 +1100 From: Peter Jeremy To: freebsd-hackers@freebsd.org Message-ID: <20060112085237.GA64401@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Subject: Atomic operations across multiple processors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 08:52:40 -0000 atomic(9) states: The current set of atomic operations do not necessarily guarantee atomic- ity across multiple processors. ... On the i386 architecture, the cache coherency model requires that the hardware perform this task, thus the atomic operations are atomic across multiple processors. On the ia64 architecture, coherency is only guaranteed for pages that are configured to using a caching policy of either uncached or write back. Unfortunately, this doesn't document the behaviour for other architectures - this makes it difficult to write portable code. For the ia64, the statement isn't especially helpful because there's no indication of what caching policy is used by default and how to change it. Also, it seems odd that write-back pages would be coherent whilst write-through pages aren't - is this a typo? The man page is also inconsistent with /sys/ia64/include/atomic.h which states that atomic operations _are_ SMP safe. I've tried looking at the mutex code to see how the iA64 achieves inter-processor synchronisation on top of (supposedly) non- synchronised atomic(9) primitives but can't find anything. I'd appreciate comments from people familiar with non-iA32 architectures. -- Peter Jeremy