[Development] Mutex future directions

[Thiago Macieira]

On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
> Hi,
> 
> Regarding valgrind:
>  *) On debug build, nothing is inlined.
>  *) If we keep it inline, then we would just need a patch like this [1]

-fno-inline doesn't help because of -fvisibility-inlines-hidden. The call 
cannot be rerouted to valgrind.

The annotation you added might help, but as I said, adding instructions -- 
even if they produce no architectural change -- still consumes CPU resources. 
I'd like to benchmark the annotation vs the function call.
> 
> Regarding Transactional memory:
>  *) Very interesting
>  *) Notice the end of section 8.2.1: "Improper use of hints will not cause
>     functional bugs though it may expose latent bugs already in the code.".
>     So in other words, we can use XAQUIRE and XRELEASE without any problem
> in inline code, without binary compaibility issue

Indeed, but note that what it says about transactions that abort too often. If 
the transaction aborts, then the code needs to be re-run non-transactionally, 
with the lock. That means decreased performance and increased power 
consumption.

Note also that all x87 instructions will abort, so any transactions around x87 
code (32-bit floating point) would cause aborts.

At this point, we don't know which mutex locks we should make transactional. 
As I said, neither you nor I have a Haswell prototype to test on. At the 
earliest, we'll be able to test this for Qt 5.2.

>  *) The other transactional model does not really apply, but even if it
> would, we could still use some different value for locked and unlocked and
> the previously inline code falls back to the non-inline code.

RTM might apply because we can get extra information about the abort and figure 
out whether that particular lock should use transactions the next time.

>  *) debugging tools (valgrind) could also detect the XAQUIRE and XRELEASE
>     prefix.
> 
> Regarding increasing the size
>  *) I think it is valuable to have small memory overhead per mutexes.
>  *) I think recursive mutex don't deserve improvements on the detriment of
>     normal ones
>  *) I think there would not be improvement on Windows.

If we don't improve for recursive mutexes and I simply don't try Windows or 
Mac, then there's no need to increase the mutex size.

Then I need only to look into QReadWriteLock.

-- 
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/20120519/78ad10e6/attachment.sig>