[Development] Mutex future directions

[Thiago Macieira]

On quarta-feira, 23 de maio de 2012 22.52.55, Carsten Breuer wrote:
> Hi Bradley,
> 
> >> And I don't think they very much liked the idea of spinning while trying
> >> to
> >> acquire a lock (consumes power)... at least we have a call to
> >> QThread::yieldCurrentThread(), though it would be interesting to see what
> >> happens if we replace it with a PAUSE instruction.
> > 
> > Have you seen the spin code in 4.8? It does use
> > QThread::yieldCurrentThread(). ;)
> I guess it depends a bit on if you want to yield to another thread or
> not ;-). Of course: burning cpu time is another way to solve this ;-)

According to the Intel manual, if you *don't* yield and you don't have the 
PAUSE instruction, you may make things worse. 

For one thing, if you don't yield, the processor will continue executing your 
code, without giving a chance for other processes to run. There's no guarantee 
even in a multiprocessor system that the other thread is running. And even if 
it's running, if it was scheduled to another thread on the same hyperthreaded 
core, the processor may not execute the that thread because this thread still 
has instructions to execute.

To make matters worse, if you spin too quickly, you issue a LOT of atomic 
compare-and-swap commands, which block the bus. So even if the other thread is 
scheduled by the OS and is running in a different core, it may have memory 
stall issues.

Hence one of the most counter-intuitive (at first glance) recommendations: to 
make your spin lock loops faster, insert a PAUSE :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120523/2bb94069/attachment.sig>