From: Jeremy Fitzhardinge Subject: Re: [PATCH RFC 02/12] x86/ticketlock: convert spin loop to C Date: Fri, 06 Aug 2010 13:33:41 -0700 Message-ID: <4C5C71A5.3050500@goop.org> References: <1280761639.1923.213.camel@laptop> <4C56E1A1.6020005@goop.org> <4C5C1F80020000780000EA6D@vpn.id2.novell.com> <4C5C21E3.1020004@goop.org> <4C5C6DCE.4020206@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C5C6DCE.4020206@zytor.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "H. Peter Anvin" Cc: Nick Piggin , Xen-devel , Peter Zijlstra , Linux Kernel Mailing List , Jan Beulich , Avi Kivity List-Id: xen-devel@lists.xenproject.org On 08/06/2010 01:17 PM, H. Peter Anvin wrote: > On 08/06/2010 07:53 AM, Jeremy Fitzhardinge wrote: >> On 08/06/2010 05:43 AM, Jan Beulich wrote: >>> You certainly mean "the compiler currently treats this as being:" - I >>> don't think there's a guarantee it'll always be doing so. >>> >>>> for (;;) { >>>> if (inc.tickets.head == inc.tickets.tail) >>>> goto out; >>>> ... >>>> } >>>> out: barrier(); >>>> } >>>> >>>> (Which would probably be a reasonable way to clarify the code.) >>> I therefore think it needs to be written this way. >> >> Agreed. >> > > A call/return to an actual out-of-line function is a barrier (and will > always be a barrier, as it is the fundamental ABI sequence points), > but to an inline function it is not. Yes. So the goto explicitly puts the barrier into the control flow which should stop the compiler from doing anything unexpected. J