Quelles sont les "choses à savoir" lorsque vous plongez dans la programmation multithread en C ++

Question

Je travaille actuellement sur une application de réseau sans fil en C ++ et il est sur le point de vouloir multi-threads de logiciels dans un processus unique, plutôt que de les avoir tous dans des processus distincts. Théoriquement, je comprends le multi-threading, mais je n'ai pas encore plongé dans la pratique.

Qu'est-ce que tout programmeur doit savoir lorsqu'il écrit du code multithread en C ++?

Answer 1

Je me concentrerais sur la conception de la chose autant que possible partitionnée afin que vous ayez le minimum de choses partagées entre les threads. Si vous vous assurez que les statiques et autres ressources ne sont pas partagées entre les threads (autres que celles que vous partageriez si vous aviez conçu cela avec des processus plutôt que des threads), tout irait bien.

Par conséquent, même si oui, vous devez garder à l'esprit des concepts tels que les verrous, les sémaphores, etc., le meilleur moyen de remédier à cette situation est d'essayer de les éviter.

Answer 2

Je ne suis pas un expert dans ce sujet. Juste une règle de pouce:

1) la Conception de la simplicité, des bugs sont vraiment difficiles à trouver dans le code concurrente, même dans les exemples les plus simples.
2) C++ vous offre un très élégant paradigme de gestion des ressources(mutex, sémaphore,...): RAII. J'ai observé qu'il est beaucoup plus facile de travailler avec boost::thread que de travailler avec des POSIX threads.
3) Construire votre code thread-safe. Si vous ne le faites pas, votre programme pourrait comporter bizarrement.

Answer 3

Je suis exactement dans cette situation: j'ai écrit une bibliothèque avec un verrou global (nombre de fils, mais seulement en cours d'exécution à un moment dans la bibliothèque) et je suis la refactorisation pour soutenir la concurrence.

J'ai lu des livres sur le sujet, mais ce que j'ai appris se dresse en quelques points:

1. pensez parallèle: imaginez une foule en passant par le code. Ce qui se passe lorsqu'une méthode est appelée alors qu'il est déjà dans l'action ?
2. pensez partagé: imaginer que beaucoup de gens essayer de lire et de modifier les ressources partagées dans le même temps.
3. conception: éviter les problèmes que les points 1 et 2 peuvent soulever.
4. ne jamais penser que vous pouvez ignorer bord des cas, ils vont vous mordre dur.

Puisque vous ne pouvez pas la preuve de tester une conception simultanée (parce que le thread d'exécution de l'entrelacement n'est pas reproductible), vous devez vous assurer que votre conception est robuste en analysant minutieusement les chemins de code et de documenter la façon dont le code est censé être utilisé.

Une fois que vous comprenez comment et où vous devez d'étranglement de votre code, vous pouvez lire la documentation sur les outils utilisés pour ce travail:

1. Mutex (accès exclusif à une ressource)
2. L'étendue des Serrures (bon motif pour verrouiller/déverrouiller un Mutex)
3. Les sémaphores (la transmission de l'information entre les threads)
4. ReadWrite Mutex (beaucoup de lecteurs, d'un accès exclusif à écrire)
5. Les signaux (façon de "tuer" un fil ou d'envoyer un signal d'interruption, comment attraper ces)
6. En parallèle des modèles de conception: boss/travailleur, producteur/consommateur, etc (voir schmidt)
7. plate-forme d'outils spécifiques: openMP, C blocs, etc

Bonne chance ! La simultanéité est amusant, il suffit de prendre votre temps...

Answer 4

Vous devriez en savoir plus sur les verrous, les mutex, les sémaphores et les variables de condition.

Un mot de conseil, si votre application a une forme quelconque d'interface utilisateur, assurez-vous de toujours la modifier à partir du fil de l'interface utilisateur. La plupart des toolkits / frameworks d'interface utilisateur planteront (ou se comporteront de manière inattendue) si vous y accédez à partir d'un thread en arrière-plan. Habituellement, ils fournissent une forme de méthode de dispatching pour exécuter une fonction dans le thread d'interface utilisateur.

Answer 5

Ne présumez jamais que les Api externes sont thread-safe. Si elle n'est pas explicitement mentionné dans leurs docs, ne pas les appeler simultanément à partir de plusieurs threads. Au lieu de cela, limiter votre utilisation d'entre eux pour un seul thread ou utiliser un mutex pour empêcher les appels simultanés (ce qui est assez similaire pour les bibliothèques GUI).

Le point suivant est lié au langage. Rappelez-vous, C++ a pas (encore) bien définis approche du filetage. Le compilateur/optimiseur ne sais pas si le code peut être appelé en même temps. L' volatile mot-clé est utile pour éviter certaines optimisations (c'est à dire la mise en cache de la mémoire des champs dans les registres du CPU) en multi-thread contextes, mais c'est pas de mécanisme de synchronisation.

Je le recommande coup de pouce pour les primitives de synchronisation. Ne salissez pas avec plate-forme Api. Ils font de votre code difficile à port parce qu'ils ont des fonctionnalités similaires sur toutes les grandes plates-formes, mais légèrement différente de détail de comportement. Boost résout ces problèmes en exposant les fonctionnalités à l'utilisateur.

En outre, si il ya même la plus petite chance qu'une structure de données qui pourrait être écrit par deux threads en même temps, utiliser les primitives de synchronisation pour le protéger. Même si vous pensez que cela ne se produira une fois dans un million d'années.