Date: Tue, 16 Jan 2001 00:55:18 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, jake@FreeBSD.org Subject: Re: Atomic ops (Was Re: cvs commit: src/sys/i386/include atomic. Message-ID: <XFMail.010116005518.jhb@FreeBSD.org> In-Reply-To: <200101160844.f0G8iFI31923@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Jan-01 Mark Murray wrote: >> > 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). Use two indices: one marks head, and the other marks the tail. New items coming in advance head with atomic_add_int(). If you use a power of 2 for the buffer size, you can use an atomic_and_int() to wrap it around to zero when needed. The harvester advances tail as it reads in entries. Don't let head go past tail when getting new entries (just drop teh new entries) (do if (head == tail) return; losing the race there will only mean you might lose a entropy entry, nothing major). The harvester only advances tail if needed. The test for if needed can be a simple condition test w/o atomic ops (make head/tail volatile though). Again, losing the race there simply means delaying a little bit to parse a new entry, nothing major lost. This can be done cheaply and easily. > 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. Keep in mind that it doesn't have to be perfect. If you lose an entry, so what. More will come in later. There are some races that for this particular device it doesn't hurt to lose. so don't waste cycles working aroud them. :) > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010116005518.jhb>