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
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