From owner-cvs-all Mon Jan 15 12:13:18 2001 Delivered-To: cvs-all@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C73C037B401; Mon, 15 Jan 2001 12:12:52 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0FKCns56756; Mon, 15 Jan 2001 13:12:51 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101152012.f0FKCns56756@aslan.scsiguy.com> To: John Baldwin Cc: Bruce Evans , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Wilko Bulte , Poul-Henning Kamp , Peter Wemm Subject: Re: cvs commit: src/sys/i386/conf GENERIC In-Reply-To: Your message of "Mon, 15 Jan 2001 11:47:17 PST." Date: Mon, 15 Jan 2001 13:12:49 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >So are you ready to write the code in trap() to handle an illegal instruction >fault in userland that decodes and executes all variants of cmpxchg? The new >threading code in libc will be using atomic_cmpset() from userland, which is >going to be the main hurdle to get over. This is the wrong way to handle it. Have atomic_cmpset() perform a fixup of the calling code on first entry and the result will be code as optimized as possible for the processor type the code is running on. If the user decides to write their own code that uses cmpxchg, they get what they deserve, but the primitives should not require a *fault* to work correctly. This is not a new idea and it honestly surprises me that everyone in this discussion seems to be avoiding the obvious and time tested solution for this kind of problem. BTW, this type of thing gives you the oportunity to optimize for any type of CPU, so the benefit is not necessarily i386 specific. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message