From owner-cvs-all Tue Jan 16 13:11: 4 2001 Delivered-To: cvs-all@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 601EF37B400; Tue, 16 Jan 2001 13:10:36 -0800 (PST) Received: from nas2-11.mea.club-internet.fr (nas2-11.mea.club-internet.fr [195.36.200.11]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA16024; Tue, 16 Jan 2001 22:10:10 +0100 (MET) Date: Tue, 16 Jan 2001 21:09:34 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matt Dillon Cc: Mark Murray , 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. In-Reply-To: <200101161749.f0GHnQD14640@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Jan 2001, Matt Dillon wrote: > :... > :> you had a circular buffer, and you used one atomic operation to increm= ent the > :> index, that would be better. The tophalf would just have to always us= e 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 > :--=20 > :Mark Murray >=20 > A bottom half / top half circular FIFO does not need to use atomic op= s > at all. The writer simply manipulates the WIndex and the reader > simply manipulates the RIndex. If you have multiple readers or=20 > multiple writers, then you have a locking issue, but if you don't the= re > are no issues. >=20 > 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. With CPUs that may prefetch reads, un read barrier is also needed at the consumer side (prior to reading buffer[RIndex]). And this one may well be also needed on Intel, at least in theory. In practice, lots of theorically broken code for Intel due to lack of consumer (read) barriers works for years. :) BTW, even when the other processor is a something on an IO BUS that performs DMA, a read barrier may be needed in order not to read stale data (prefetched) instead of DMAed data, and this also apply to Intel. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message