Date: Tue, 16 Jan 2001 10:44:19 +0200 From: Mark Murray <mark@grondar.za> To: John Baldwin <jhb@FreeBSD.org> Cc: 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: <200101160844.f0G8iFI31923@gratis.grondar.za> In-Reply-To: <XFMail.010116002609.jhb@FreeBSD.org> ; from John Baldwin <jhb@FreeBSD.org> "Tue, 16 Jan 2001 00:26:09 PST." References: <XFMail.010116002609.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101160844.f0G8iFI31923>