From owner-freebsd-arch Sun Jan 20 13:25:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id F3E1537B416 for ; Sun, 20 Jan 2002 13:25:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g0KLPqf31593; Sun, 20 Jan 2002 16:25:52 -0500 (EST) (envelope-from wollman) Date: Sun, 20 Jan 2002 16:25:52 -0500 (EST) From: Garrett Wollman Message-Id: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu> To: Michal Mertl Cc: arch@FreeBSD.org Subject: Re: 64 bit counters again In-Reply-To: References: <3C48FCEF.9190CA08@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I hope you'll forgive me for reopening this up to -arch again.... < said: > But compare and exchange or conditional move insns should be there. > And because the platform is fully 64 bit AFAIK I'd expect at least > 64 bit variants of them. The cache coherency problem is also > unrelated - it's there whatever size you have. The ultimate upshot of this is that it does not make sense to expose low-level primitives (such as compare-exchange or LL/SC) directly in the API. This is because each processor architecture will have its own requirements for coherency, in some cases requiring specialized instructions which a compiler would not normally generate, and often requiring memory barriers inside the spin loop. However, we can easily define a set of basic operations which every architecture we currently support can implement reliably and coherently without locking, including incrementing counters and updating some kinds of linked lists. (This has been proven both formally and by construction; see a recent Algorithms textbook.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message