Date: Tue, 16 Jan 2001 00:26:09 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Mark Murray <mark@grondar.za> 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: <XFMail.010116002609.jhb@FreeBSD.org> In-Reply-To: <200101160806.f0G86GI31855@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Jan-01 Mark Murray wrote:
>> > particularly if I just do a
>> >
>> > if (mutex_try_enter(foo, ...)) {
>> > /* Harvest */
>> > :
>> > mutex_exit(foo, ...);
>> > }
>> >
>> > How much of a difference would it make if I were to use atomic ops like
>> >
>> > if (atomic_cmpset(foo, 0, 1)) {
>> > /* harvest */
>> > :
>> > foo = 0;
>> > }
>>
>> You would have to use atomic_store_rel() here. And you would have to use
>> atomic_cmpset_acq() since you are protecting something.
>
> Right. I'm getting a grasp of whats going on here :-)
>
>> Since you are doing atomic operations with memory barriers either way, I'm
>> not
>> sure that the mutex is that much slower, to be perfectly honest.
>
> 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.
--
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.010116002609.jhb>