From owner-cvs-all Mon Oct 8 23:56:14 2001 Delivered-To: cvs-all@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id D882B37B407 for ; Mon, 8 Oct 2001 23:56:06 -0700 (PDT) Received: (qmail 25292 invoked from network); 9 Oct 2001 06:56:06 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Oct 2001 06:56:06 -0000 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: <200110090640.f996eeo10518@earth.backplane.com> Date: Mon, 08 Oct 2001 23:55:34 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: cvs commit: src/sys/i386/include atomic.h Cc: Poul-Henning Kamp , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Oct-01 Matt Dillon wrote: > >:> atomic ops at all is a terrible idea, especially after all the hell >:> people doing the alpha and IA64 ports went through (are going through?) >:> with the current kernel atomic ops. >: >:Erm, what "hell" regarding the current atomic ops exactly? The current >:method >:of handling memory barriers is quite ia64 friendly and works on alpha, ia64, >:sparc64, and ppc so far (and x86). The only really critical ops are >:atomic_cmpset() (you could build everythign else up from that). > > Shoot, I don't remember... when I was cleaning up the VM stuff someone > asked if I could remove the atomic_ bit set and clear ops in -current. > Apparently those played hell with one of the ports. That is due to things like atomic_add_short, etc. Those are painful, and the short and char operations are going away. (It's the short and char parts that are painful on ppc and sparc64.) The only operations that will probably be used in userland are atomic_cmpset(), atomic_set(), atomic_clear(), and atomic_store(). > Nobody is saying you can't have atomic operations.. only that they > (1) should not be exposed to userland in general and (2) should not > try to leech off the kernel functions. It's hard enough working on > the kernel and having to worry about interactions with other parts > of the kernel. Now we have to worry about interactions against userland > as well? It's a bad idea. They will probably only be used in the internals of libpthread for the KSE stuff. I doubt they will see much use if any outside of that since threaded programs will rely on the mutexes in the pthreads API. > -Matt -- 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 cvs-all" in the body of the message