From owner-freebsd-arch  Thu Oct 12  8:34:24 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 878FA37B503; Thu, 12 Oct 2000 08:34:19 -0700 (PDT)
Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1])
	by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id JAA16007;
	Thu, 12 Oct 2000 09:23:13 -0600 (MDT)
Message-Id: <200010121523.JAA16007@berserker.bsdi.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Mike Smith <msmith@freebsd.org>, arch@freebsd.org
Subject: Re: we need atomic_t 
In-reply-to: Your message of "Thu, 28 Sep 2000 11:39:09 PDT."
             <20000928113907.V7553@fw.wintelcom.net> 
From: Chuck Paterson <cp@bsdi.com>
Date: Thu, 12 Oct 2000 09:23:13 -0600
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


	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