Date: Tue, 17 May 2011 11:51:17 -0400 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Max Laier <max@love2party.net>, FreeBSD current <freebsd-current@freebsd.org>, neel@freebsd.org, Peter Grehan <grehan@freebsd.org> Subject: Re: proposed smp_rendezvous change Message-ID: <201105171151.18038.jhb@freebsd.org> In-Reply-To: <4DD28781.6050002@FreeBSD.org> References: <4DCD357D.6000109@FreeBSD.org> <201105170958.16847.jhb@freebsd.org> <4DD28781.6050002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote: > on 17/05/2011 16:58 John Baldwin said the following: > > No, it doesn't quite work that way. It wouldn't work on Alpha for example. > > > > All load_acq is a load with a memory barrier to order other loads after it. > > It is still free to load stale data. Only a read-modify-write operation > > would actually block until it could access an up-to-date value. > > Hmm, ok. > How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-) > Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value, > if there could be any. > Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ? > > You see at what I am getting? Yeah, either of those would work. At this point just leaving the atomic_add_int() as-is would be the smallest diff. :) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105171151.18038.jhb>