Date: Mon, 21 Jan 2002 08:36:26 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Michal Mertl <mime@traveller.cz>, arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <20020121083625.A72285@gsmx07.alcatel.com.au> In-Reply-To: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sun, Jan 20, 2002 at 04:25:52PM -0500 References: <3C48FCEF.9190CA08@mindspring.com> <Pine.BSF.4.41.0201192049201.43404-100000@prg.traveller.cz> <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jan-20 16:25:52 -0500, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
>The ultimate upshot of this is that it does not make sense to expose
>low-level primitives (such as compare-exchange or LL/SC) directly in
>the API. This is because each processor architecture will have its
>own requirements for coherency, in some cases requiring specialized
>instructions which a compiler would not normally generate, and often
>requiring memory barriers inside the spin loop.
Agreed.
>However, we can easily define a set of basic operations which every
>architecture we currently support can implement reliably and
>coherently without locking, including incrementing counters and
^^^^^^^ protecting the operation by a separate
mutex or semaphore-style lock.
>updating some kinds of linked lists.
Some form of inter-processor locking is required, but the low=level
primitives implicitly achieve this.
We already have a MI API for much of this in /sys/<arch>/include/atomic.h
Peter
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?20020121083625.A72285>