From mboxrd@z Thu Jan  1 00:00:00 1970
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
Date: Mon, 14 Jun 2010 10:05:55 -0700
Subject: [ltt-dev] [PATCH 1/3] Fix the "unknown" case
In-Reply-To: <4C165E12.2000803@redhat.com>
References: <20100611195937.GA18891@linux.vnet.ibm.com>
	<1276286430-21147-1-git-send-email-paulmck@linux.vnet.ibm.com>
	<20100613212828.GG5427@Krystal>
	<20100614004125.GI2428@linux.vnet.ibm.com>
	<4C165E12.2000803@redhat.com>
Message-ID: <20100614170555.GA2338@linux.vnet.ibm.com>

On Mon, Jun 14, 2010 at 06:51:30PM +0200, Paolo Bonzini wrote:
> On 06/14/2010 02:41 AM, Paul E. McKenney wrote:
> >The compiler (and sometimes the CPU) are within their rights to move
> >code into a lock-based critical section.  With two
> >locks:
> >
> >	do_first_thing();
> >	acquire_lock();
> >	release_lock();
> >	acquire_lock();
> >	release_lock();
> >	do_second_thing();
> >
> >the worst that the compiler and CPU can do is:
> >
> >	acquire_lock();
> >	do_first_thing();
> >	release_lock();
> >	acquire_lock();
> >	do_second_thing();
> >	release_lock();
> >
> >which is still acting like a memory barrier.
> 
> Interesting, so it's actually the release+acquire that is doing the
> job.  I thought about barrier+acquire+release+barrier, but that
> would placate the compiler only, not the CPU.

Strange but true!  ;-)

							Thanx, Paul