Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Oct 2001 23:40:40 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Poul-Henning Kamp <phk@critter.freebsd.dk>
Subject:   Re: cvs commit: src/sys/i386/include atomic.h
Message-ID:  <200110090640.f996eeo10518@earth.backplane.com>
References:   <XFMail.011008232921.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

:>     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.

:>     It is far better to have *high* level userland operations, like userland
:>     mutexes (which BTW should be entirely independant of kernel mutexes),
:>     and not expose low level so-called atomic ops to userland at all.
:
:How does one implement the userland mutexes w/o atomic operations?  I agree
:they don't need to be the same code as kernel mutexes as the "hard" cases where
:you block a thread, etc. will definitely be entirely different.
:
:>                                               -Matt
:
:-- 
:
:John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/

    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.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110090640.f996eeo10518>