[Development] Mutex future directions

[Thiago Macieira]

On terça-feira, 22 de maio de 2012 07.12.26, bradley.hughes at nokia.com wrote:
> So far, we've got 3 votes for de-inlining: Thiago, Lars, and myself. For the
> few cases where inlining matters, we can inline inside Qt at those
> locations (QMetaObject::activate() would be the first place to check).

Turns out that I got some unexpected extra ammo for this decision. Apparently, 
some people from Intel found out about this thread and came to me to ask WTH I 
was thinking. Fortunately, they also offered help :-)

We discussed a few ideas back and forth. Summarising:

 - inlining the lock code should be done on a need-to-do basis, only where the 
performance is really critical

 - such inlined locks should or should not use Transactional Memory only after 
we've done testing to ensure the performance

 - for generic locks, the overhead of a function call is usually negligible 
and will be drowned out by the rest of the work to be done

 - for those generic locks, transactional memory use needs to be adaptative. 
That means we need to use the RTM instructions, which require a CPUID check. 
That check and the presence of the abort handler mean that we transactional 
memory code would be non-inline.

 - if we were to keep the inlined locking code, we'd need to change the 
default value of QMutex's d pointer so that the inlined compare-and-swap 
always fails. That means the code path for locking a mutex on x86 will always 
include a *failed* compare-and-exchange on Haswell.

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.

-- 
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/20120522/1639017b/attachment.sig>