From mboxrd@z Thu Jan  1 00:00:00 1970
From: pbonzini@redhat.com (Paolo Bonzini)
Date: Mon, 14 Jun 2010 18:52:43 +0200
Subject: [ltt-dev] [PATCH 1/3] Fix the "unknown" case
In-Reply-To: <20100614004125.GI2428@linux.vnet.ibm.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>
Message-ID: <4C165E5B.1090402@redhat.com>

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.

Paolo