[Development] Mutex future directions

[Olivier Goffart]

On Saturday 19 May 2012 19:05:58 Thiago Macieira wrote:
> 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.

Visibility does not really matter for valgrind. It does address redirection, 
using the debug symbols.

You can see it works by trying the attached wrapper.c

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

Yes, they have a cost which I am not sure we want to pay on release build.


> > Regarding Transactional memory:

> >  *) 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 compatibility 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.

Yes, but we are talking about the rare case in which a QMutex is shared 
between two different objects compiled with different version of Qt.
And in that unlikely case, one can just recompile to fix the performance 
issue.

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

Indeed, QMutex can be used for all sort of cases.  There can be also way too 
much code in the critical section to fit into the transaction cache. 
Or maybe there is side effects.

QMutexLocker lock(&mutex)
qDebug() << "What now?  does it also restart the transaction?"


So it is probably bad to do the lock elision within QMutex...  
We need to test it on real hardware to see if it works.

But my point is that the current QMutex architecture does not keep us from 
using lock elision later.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrapper.c
Type: text/x-csrc
Size: 1440 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120520/e1401c7f/attachment.c>