Date: Tue, 31 Oct 2000 11:55:07 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Chuck Paterson <cp@bsdi.com> Cc: Cedric Berger <cedric@wireless-networks.com>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-smp@FreeBSD.ORG Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <20001031115506.Y22110@fw.wintelcom.net> In-Reply-To: <200010311857.LAA02433@berserker.bsdi.com>; from cp@bsdi.com on Tue, Oct 31, 2000 at 11:57:09AM -0700 References: <20001031102110.V22110@fw.wintelcom.net> <200010311857.LAA02433@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Chuck Paterson <cp@bsdi.com> [001031 10:57] wrote:
> Alfred,
>
> I'm a little surprised. I thought you won the argument to
> use atomic operations as long as long as all the needed operations
> such as the decrement and test, and examine without modification
> were present. You certainly convinced me. I though we had got to
> the point of just working out what we wanted to do for size.
>
> This is of course only where a mutex isn't already required
> for internal data integrity.
Robert Watson's explanation on how he was going to handle atomic
ops with mutexes rather than discussing my proposed atomic_t (or
atomicref_t) made it pretty clear that either he has somehow missed
(happens to disagree with) my proposals.
I've also been unable to convice the SMP project leader Jason Evans
and the main smp coder Jonathan Baldwin of the merits of atomic_t.
My proposal is a simple atomic type that has these features:
1) needs to be 'constructed' and 'destroyed' via functions
2) offers at least/about 24 bits of precision
3) (optional) supports AND/OR ops
4) supports increments and decrements with a special "decrement and
return if 0 has been reached"
The virtues of atomic_t are:
1) cheaper (if not abused, meaing one probably shouldn't implement something
like the tcpstats struct using atomics because you may need to perform
several atomic ops in a row and it would be cheaper to hold a mutex over
the entire struct)
2) less storage requirement on most archs (enjoy the bloat on ucred
:( if you use mutexes all over)
3) if an arch doesn't support atomic memory ops the con/destructors can
be used to initialize a mutex within the machine depandant struct.
4) non blocking on most archs that support it without mutexes
Linux supports these ops through includes/arch/asm-{arch}/atomic.h
headers if anyone cares to check out what's faster and possible and
cleaner.
I'm tired of trying to reach concensus on the issue.
Robert, if you like this let me know and I'll hand you what I have
so far which are the patches for i386.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001031115506.Y22110>