Date: Sun, 20 Jan 2002 16:25:52 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Michal Mertl <mime@traveller.cz> Cc: arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.BSF.4.41.0201192049201.43404-100000@prg.traveller.cz> References: <3C48FCEF.9190CA08@mindspring.com> <Pine.BSF.4.41.0201192049201.43404-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
I hope you'll forgive me for reopening this up to -arch again.... <<On Sat, 19 Jan 2002 21:20:26 +0100 (CET), Michal Mertl <mime@traveller.cz> said: > But compare and exchange or conditional move insns should be there. > And because the platform is fully 64 bit AFAIK I'd expect at least > 64 bit variants of them. The cache coherency problem is also > unrelated - it's there whatever size you have. 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. 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 updating some kinds of linked lists. (This has been proven both formally and by construction; see a recent Algorithms textbook.) -GAWollman 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?200201202125.g0KLPqf31593>