Posté par
brouillon() le 23/05/2006 à 09:23. (lien). Évalué à 8.
> ben l'api des thread posiw est pas vraiment complexe .... bon c'est
> sur tu geres tous les access toi même mais je dirai chiant ou long
> mais pas compliqué .
La gestion des threads en C/C++ est compliqué par le fait que ces deux langages ne possede aucune primitives de concurence et de gestion des threads en interne.
Si effectivement au premier abord tu peux avoir l'impression que ce n'est pas si compliqué de faire du multithread en C/C++, le fait est que dans le cas d'applications réelles (autre que toy-app) le programmeur se trouve confronté à de nombreux bugs, non reproductibles, très difficille à trouver et encore plus à éliminer.
> "Ou alors, les threads sont indépendants, et alors, pourquoi en
> utiliser en premier lieu ?" ben pour parallèliser le traitement
> ( archi multi-proc tous ca ... )
Les threads peuvent en effet etre utilisé pour accelerer certain traitement. Mais ceci n'est qu'un cas particulier de leur utilisation.
De mon point de vu, les threads permettent surtout d'offrir aux programmeurs un acces au paradigme de la programmation concurente.
L'intérêt n'est pas d'aller plus vite, c'est surtout de coder plus simplement certain type de probleme très complexe qui se pretent mieux à mode de pensée.
> et pourquoi pas des fork a la place? ben histoire de changement
> de contexte plus court ...
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose (Ce n'est pas le cas sur tout les OS, et Solaris possede une gestion des threads réellement intéressante).
Ce sont dans les fait des processus kernel-land avec comme seul difference que pour les threads ces processus partage le même espace mémoire. le scheduling se fait ensuite par le kernel comme n'importe quel process et "quasiment" à la même vitesse.
Voir ainsi l'appel system clone
$ man clone =>
NAME
clone - create a child process
DESCRIPTION
clone creates a new process, just like fork(2).
...
The main use of clone is to implement threads: multiple threads
of control in a program that run concurrently in a shared
memory space.
Il me semble que fork (...) fait appel à clone dans les fait
Re: ...
> ben l'api des thread posiw est pas vraiment complexe .... bon c'est
> sur tu geres tous les access toi même mais je dirai chiant ou long
> mais pas compliqué .
La gestion des threads en C/C++ est compliqué par le fait que ces deux langages ne possede aucune primitives de concurence et de gestion des threads en interne.
Si effectivement au premier abord tu peux avoir l'impression que ce n'est pas si compliqué de faire du multithread en C/C++, le fait est que dans le cas d'applications réelles (autre que toy-app) le programmeur se trouve confronté à de nombreux bugs, non reproductibles, très difficille à trouver et encore plus à éliminer.
Le gestion des threads à travers une bibliotheque est d'ailleur très critiquée. voir :
"Threads Cannot be Implemented as a Library"
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
qui en detaille les raisons
> "Ou alors, les threads sont indépendants, et alors, pourquoi en
> utiliser en premier lieu ?" ben pour parallèliser le traitement
> ( archi multi-proc tous ca ... )
Les threads peuvent en effet etre utilisé pour accelerer certain traitement. Mais ceci n'est qu'un cas particulier de leur utilisation.
De mon point de vu, les threads permettent surtout d'offrir aux programmeurs un acces au paradigme de la programmation concurente.
L'intérêt n'est pas d'aller plus vite, c'est surtout de coder plus simplement certain type de probleme très complexe qui se pretent mieux à mode de pensée.
> et pourquoi pas des fork a la place? ben histoire de changement
> de contexte plus court ...
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose (Ce n'est pas le cas sur tout les OS, et Solaris possede une gestion des threads réellement intéressante).
Ce sont dans les fait des processus kernel-land avec comme seul difference que pour les threads ces processus partage le même espace mémoire. le scheduling se fait ensuite par le kernel comme n'importe quel process et "quasiment" à la même vitesse.
Voir ainsi l'appel system clone
$ man clone =>
NAME
clone - create a child process
DESCRIPTION
clone creates a new process, just like fork(2).
...
The main use of clone is to implement threads: multiple threads
of control in a program that run concurrently in a shared
memory space.
Il me semble que fork (...) fait appel à clone dans les fait
[ Répondre ]