Date: Tue, 16 Jan 2001 09:49:26 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Mark Murray <mark@grondar.za> Cc: John Baldwin <jhb@FreeBSD.ORG>, jake@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: Atomic ops (Was Re: cvs commit: src/sys/i386/include atomic. Message-ID: <200101161749.f0GHnQD14640@earth.backplane.com> References: <XFMail.010116002609.jhb@FreeBSD.org> <200101160844.f0G8iFI31923@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101161749.f0GHnQD14640>