Bien.
Les pthreads sont un sujet hyper classique, il y a l'embarras des choix pour la doc.
Mais comme t'es déjà initié, cette introduction illustrée sera parfaite pour toi.
->si t'es "anglaisglotte", tant mieux, sinon faut pas avoir peur, c'est principalement des mots techniques, très facile à comprendre.
(de toutes façons, les meilleurs docs sont anglais !)
Si qq1 te recommande "Programming with POSIX Threads", c'est qu'il t'aime pas.
A vrai-dire, la notion de thread en elle-même n'est pas si difficile à comprendre que ça, et l'introduction de Blaise Barney délivre l'essentiel à savoir. Pour trouver mieux après ça, il ne sert à rien de délaisser Dieu pour ses saints, le plus simple est d'utiliser la spec elle même. Voici un point d'entrée avec pthread_create().
Après, le sujet est plus vaste que ça. Le modèle des threads lui-même est discutable. Tous les modèles de programmation à "partage d'état" (shared state), c-a-d qui utilisent en gros un bout de mémoire partagée pour se synchroniser montrent leur limites avec la taille (du projet). Ils ne sont pas "scalable". Tant que le code ne dépasse pas qqes milliers de lignes, c'est plus ou moins gérable, mais au delà, les "live/deadlocks", "race conditions", et autres "starvations" deviennent un vrai casse-tête à tel point qu'il devient impossible de *garantir* que le code est exempt de tels soucis !
(De même pour la gestion de la mémoire tout simplement, il est déraisonnable de confier les new/malloc/free/delete.. aux développeurs quand le code fait 50 milles lignes. Le ramasse-miettes devient une nécessité. Comme pour les deadlock/race conditions et autres, toute une culture s'est développée autour des fuites de mémoires en tous genres, et autres "overrun" et "overflows" qui posent des risques de stabilité et de sécurité).
Avec la pression imposée par l'évolution du matériel (processeurs multiples, GPGPU), plusieurs tentatives ont été faite pour apprivoiser la programmation concurrente, et il est clair que ceux qui veulent simplifier la tache aux développeurs ont beaucoup de mal. En même temps, cela a ravivé d'anciennes techniques qui semblent beaucoup plus saines pour gérer des process parallèles. L'idée étant de supprimer la mémoire partagée, et d'utiliser plutôt un système de "messaging". Dans ce modèle, les protagonistes ne font qu'échanger des messages, et chacun vit dans son enclos bien protégé, où son seul contact avec le monde extérieur est sa boîte aux lettres. Tous les problèmes liée à l'état partagé s'évaporent d'un coup, et il devient soudain possible de monter en volume jusqu'à des dizaines de milliers de process parallèles de façon robuste, et sans y perdre son latin ! (Twitter). Il devient même possible de distribuer le traitement sur le réseau facilement, sans problèmes de locks ingérables..
Cela est représenté par le modèle d'acteurs, ou on parle des fois de "système d'agents" (chaque process étant un agent indépendant interagissant avec les autres agents).