From owner-cvs-all Tue Jan 16 10:26:50 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 95F1F37B400; Tue, 16 Jan 2001 10:26:21 -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 f0GIPwI33543; Tue, 16 Jan 2001 20:26:01 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101161826.f0GIPwI33543@gratis.grondar.za> To: Matt Dillon 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: <200101161749.f0GHnQD14640@earth.backplane.com> In-Reply-To: <200101161749.f0GHnQD14640@earth.backplane.com> ; from Matt Dillon "Tue, 16 Jan 2001 09:49:26 PST." Date: Tue, 16 Jan 2001 20:26:02 +0200 From: Mark Murray Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. I have multiple writers, and a single reader. Perhaps making the issue easier is the fact that I don't mind losing harvested events, so if a writer can't write, tough luck, do nothing and return. > 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. This is the way I've got it, more-or-less. I'm hoping for a method that does not involve memory barriers, if I can. I'm playing with ideas right now. 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