From owner-cvs-all Tue Jan 16 9:50:15 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 9DBBE37B402; Tue, 16 Jan 2001 09:49:50 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0GHnQD14640; Tue, 16 Jan 2001 09:49:26 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Jan 2001 09:49:26 -0800 (PST) From: Matt Dillon Message-Id: <200101161749.f0GHnQD14640@earth.backplane.com> To: Mark Murray Cc: John Baldwin , 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: <200101160844.f0G8iFI31923@gratis.grondar.za> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... :> 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 A bottom half / top half circular FIFO does not need to use atomic ops at all. The writer simply manipulates the WIndex and the reader simply manipulates the RIndex. If you have multiple readers or multiple writers, then you have a locking issue, but if you don't there are no issues. On a non-intel box that does not guarentee write ordering, you would need a memory barrier function prior to updating the WIndex to ensure that the FIFO data is in place as of the time the reader tests its RIndex against the WIndex. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message