Le concept de lock-free programming est vraiment intéressant : empêcher les possibilités de blocages, ou les erreurs lors de l'utilisation d'une mémoire partagée entre plusieurs threads. L'idée étant de ne pas utiliser de mutex, et soit de séquentialiser l'accès à la mémoire partagée, soit d'utiliser des petites opérations atomiques (qui seront exécutée sans interruptions).
Il n'est pas tellement vraisemblable de créer un gros programme lock-free, l'idée est plutôt de rester pragmatique et de faire interagir plusieurs parties lock-free entres elles.
Le gain en performance par rapport à des mutex est assez flagrant. Et c'est à mettre en place pour coder efficacement sur du multi-processeur. Mais les compétences pour une mise en œuvre correcte sont aussi plus grandes.
"So keep mutexes, unless you have a lot of lock contention or are looking for a challenge."

Une autre ressource sur le sujet :
http://woboq.com/blog/introduction-to-lockfree-programming.html
Et comment gérer des opérations atomiques en Qt :
http://qt-project.org/doc/qt-5/qatomicint.html

Une définition assez claire de "thread-safe" et "reentrant".

Ok, je crois que je vais me coltiner ça.

Des bibliothèques (et exemples d'applications) sous Qt pouvant s'avérer utiles à l'occasion.

Utilisation avancée de qmake, notamment la gestion des variables. Voilà ce que je cherchais depuis quelques temps...

Arg, pour connecter un QObject qui a été forward declared (class MyQObject dans le .h de l'utilisateur), il ne faut pas oublier d'inclure réellement le .h du QObject (dans le .cpp de l'utilisateur) pour éviter l'erreur à la compile : "No matching function for call to connect".

QString de Qt : "Tant que l'objet est copié, passé en paramètre, .... l'objet n'est pas dupliqué (tous les objets pointes vers le même espace mémoire)."
Eh je ne savais pas que QString était un QSharedDataPointer ! Bien !

Pourquoi n'est-ce pas le cas des String en Java ? Sur un gros projet auquel je participe, des devs se sont "amusés" à concaténer crapuleusement des String Java. Et hop, une nouvelle instance de String à chaque fois ! La mémoire globale le ressent... et franchement, on n'avait pas besoin de ça !