From owner-cvs-all Tue Jan 16 0:44:54 2001 Delivered-To: cvs-all@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 2530137B400; Tue, 16 Jan 2001 00:44:25 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f0G8iFI31923; Tue, 16 Jan 2001 10:44:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101160844.f0G8iFI31923@gratis.grondar.za> To: John Baldwin Cc: jake@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: Atomic ops (Was Re: cvs commit: src/sys/i386/include atomic. References: In-Reply-To: ; from John Baldwin "Tue, 16 Jan 2001 00:26:09 PST." Date: Tue, 16 Jan 2001 10:44:19 +0200 From: Mark Murray Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > OK. What I needed to know! I'll figure out an alternative logic. Which > > are the "cheaper" atomic ops, and which are the ones to avoid? > > Anything with acq and rel memory barriers (which you will likely need > unfortunately) are expensive. :-P Now, if you can pull a trick where you > you had a circular buffer, and you used one atomic operation to increment the > index, that would be better. The tophalf would just have to always use atomic > ops when acessing the index as well. OK! That's what I was thinking of, but I'd have to do a (non barrier) test-and-set operation in the harvester _and_ the top half (I think). This is going to be a nasty problem, as the harvesting action requires a little bit of work, and there is a lot of potential for multiple harvesters to stomp all over each other. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message