Date: Thu, 12 Oct 2000 09:23:13 -0600 From: Chuck Paterson <cp@bsdi.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Mike Smith <msmith@freebsd.org>, arch@freebsd.org Subject: Re: we need atomic_t Message-ID: <200010121523.JAA16007@berserker.bsdi.com> In-Reply-To: Your message of "Thu, 28 Sep 2000 11:39:09 PDT." <20000928113907.V7553@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems to me that the problem with atomic_t is that there
is no place in MI code where it is safe to use this because it
doesn't have a guaranteed size.
It seem like variables should be sized correctly by the
person writing the code. The atomic would then do whatever is
necessary to make the operation atomic. If this means acquiring
and releasing a mutex then that is the right answer because the
atomic op should not have been used in cases where there is another
way to provide the protection.
It seems like we might want atomic_32_t and all of
its relatives. Something like
struct {
u_int32_t atom;
} atomic_32_t;
All the atomic operation would expect this and any
place that accidently tried to operate on the data in an unsafe
manner could be flagged at compile time.
In the above scheme we might also not guarantee the
size of the struct just the effective size of the atom. That way
we could have extra storage for use by the atomic op code if needed.
Chuck
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010121523.JAA16007>