[Development] Mutex future directions

[Olivier Goffart]

On Saturday 19 May 2012 07:30:56 lars.knoll at nokia.com wrote:
> A few comments from my side:
> 
> * I am not a big fan of inlining the public classes neither. It feels a
> bit like over-optimizing at the wrong place. Reason is that this might
> make it a impossible later on to refactor our code.

In general, I agree. (This is why I was againt the fact that the new QMetaType 
API is inline)

But in this case, we are talking about very little specially crafted 
instructions, on a critical path.

Nothink compared to the complexity of, say, QString or QVector.

The instructions are made so that any unexpected value will fallback to non 
inline code.

> * It's ok to have some low level inline class for internal use if that
> helps us in performance critical parts (such as signal/slot code). Nothing
> says this and the public QMutex class have to be the same.

QBasicMutex it is internal. (but is still used directly by QMutex)

> * IMO we should really try to allow using tools such as helgrind also with
> release build

This would indeed ease the use case of developper who are developping against 
packaged version of Qt.

But I beleive they should still get a debug version of Qt, because the debug 
version offer much more ASSERT and qWarning that are stripped out of a release 
version.

> * it would be good to see how much of a real world (ie. not with
> artificial benchmarks) difference you get due to inlining the mutex code.
> Is it really relevant?

I agree with that. One needs to run benchmark :-)

-- 
Olivier

Woboq - Qt services and support - http://woboq.com