[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-build
Subject:    Re: [Boost-build] x86 CPU spinning should use pause
From:       "Hite, Christopher" <Christopher.Hite () partner ! commerzbank ! com>
Date:       2011-10-05 11:26:44
Message-ID: 56888C35366397458A8FA0626BA836F119A4E0CD7B () SE002568 ! cs ! commerzbank ! com
[Download RAW message or body]


I tried it out and you're right:

void pause() {
	__asm__ __volatile__("pause;");
}

void rep_nop() {
	__asm__ __volatile__( "rep; nop" : : : "memory" );  // copied from BOOST_SMT_PAUSE \
yield_k.hpp }

080483c4 <_Z5pausev>:
 80483c4:       55                      push   %ebp
 80483c5:       89 e5                   mov    %esp,%ebp
 80483c7:       f3 90                   pause
 80483c9:       5d                      pop    %ebp
 80483ca:       c3                      ret

080483cb <_Z7rep_nopv>:
 80483cb:       55                      push   %ebp
 80483cc:       89 e5                   mov    %esp,%ebp
 80483ce:       f3 90                   pause
 80483d0:       5d                      pop    %ebp
 80483d1:       c3                      ret



Still the other points in the Intel paper are valid.  If you fail a CAS you should \
probably loop and read it.  Otherwise if multiple threads are waiting they'll rip the \
cache line back and forth.


Also the impl calls nanosleep(), which kind of scares me because I would expecting \
the spin mutex to spin. If this happens often, we should be using OS mutexes.

The time on the OS sleeps is >> 1us, on my Linux ~3ms.  1us is probably way greater \
than 33 spins you do before calling sleep.


Ok, I realize spinlock is in::detail.  As long as asio doesn't use it, I'm fine.  \
I've stopped using it.  I'm doing low latency work and stuff like that scares me a \
bit.  As long as I don't do any atomic_exchange() of shared_ptr, I should be fine.

Chris


-----Original Message-----
From: boost-build-bounces@lists.boost.org \
                [mailto:boost-build-bounces@lists.boost.org] On Behalf Of Jeremiah \
                Willcock
Sent: Tuesday, October 04, 2011 5:35 PM
To: Boost.Build developer's and user's list
Subject: Re: [Boost-build] x86 CPU spinning should use pause

On Tue, 4 Oct 2011, Hite, Christopher wrote:

> 
> Sorry for posting to boost-build.  I mean to do users.
> 
> According to this Intel forum they take different times:
> http://software.intel.com/en-us/forums/showthread.php?t=48371
> That means they can't be the same instruction.  I'd trust their whitepaper.
> 
> Pause and no-op are two different use cases.  No-ops can allow a 
> debugger to put jumps into the code.  This pause instruction means 
> flush out memory operations.

Pause is not the same as the normal nop, but it is the same as rep-nop (they produce \
the exact same machine code).  See the page that I linked to about that.

-- Jeremiah Willcock

> 
> 
> 
> -----Original Message-----
> From: boost-build-bounces@lists.boost.org 
> [mailto:boost-build-bounces@lists.boost.org] On Behalf Of Jeremiah 
> Willcock
> Sent: Wednesday, September 28, 2011 7:12 PM
> To: Boost.Build developer's and user's list
> Subject: Re: [Boost-build] x86 CPU spinning should use pause
> 
> On Wed, 28 Sep 2011, Hite, Christopher wrote:
> 
> > #define BOOST_SMT_PAUSE __asm__ __volatile__( "rep; nop" : : : 
> > "memory" );
> > 
> > We should probably use:
> > __asm__ __volatile__("pause;")
> > 
> > Why? Because one thread polling( or worse CASing) memory, causes multiple \
> > overlapping memory operations to be made:
> 
> See
> http://stackoverflow.com/questions/7086220/what-does-rep-nop-mean-in-x
> 86-assembly
> -- basically, "rep; nop" is exactly the same instruction as "pause".
> 
> -- Jeremiah Willcock
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic