[Development] Mutex future directions

[Thiago Macieira]

On quarta-feira, 23 de maio de 2012 23.44.57, Carsten Breuer wrote:
> Hi Thiago,
> 
> thanks for clearing this :-)
> 
> >> 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.
> 
> What do you exactly mean with a PAUSE instruction. Is this a assembler
> processor command?

The PAUSE instruction on x86. I don't know of equivalent in other 
architectures.

Trivia: the instruction is encoded as "REP NOP".

> 
> > 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.
> 
> Interesting. Wouldn't it be better to change YieldCurrentThread?
> I guess, most of us are not aware of this and some of us
> learned in the 386 century that give back CPU performance to the OS is
> always a good thing. I guess it is even nowadays a good thing on single
> core machines. Isn't it?

The yieldCurrentThread call is a system call: it tells the OS to think about 
scheduling another thread. The PAUSE instruction is a processor-only hint. 
They have different purposes and we should benchmark.

-- 
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/de84ec6d/attachment.sig>