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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to