Manuel VACELET wrote:
Alexis ROLLAND wrote:
Pour r�soudre le m�me pb aujourd'hui, on utilise plut�t des prosessus
l�gers (threads) qui simplifient grandement la programmation et
permettent une communication interprocessus souple.
Bien entendu, les threads _permettet_ l'utilisation des mutex,
s�maphores...
Je dirais plutot "n�c�ssitent", les mutex et s�maphores sont l� pour
regler un probleme : tous les threads ont acces a toute la m�moire du
programme.
Je ne pense pas que l'on puisse se "r�jouir" d'avoir a utiliser des
mutex et des s�maphores.
Je suis d'accord pour le n�cessitent, bien que l'utilisation de mutex ou
de s�maphores soit soumise au besoin de les utiliser (s'il n'y a aucune
ressource � prot�ger, on se passe de ces outils).
Par contre, dire qu'il faut les utiliser car un thread a acc�s � toute
la m�moire du programme est � mon avis une erreur.
Les mutex, s�maphores et consors ont �t� cr��s d�s lors qu'il a �t�
possible de faire du multit�che. Un probl�me du multit�che est qu'il
faut s'assurer qu'une ressource n'est pas utilis�e avant de l'utiliser.
Cette ressource peut �tre de la m�moire, mais aussi (et surtout) des
�l�ments (logiciels ou mat�riels) ne supportant pas "plusieurs acc�s en
m�me temps" (port E/S, convertisseur, fichier...).
Les m�canismes de protection de ressources �taient l� donc bien avant
les threads et ceux-ci, au m�me titre que les processus lourds, ont
parfois besoin de s'en servir, m�me si effectivement, �a ne r�jouit
personne ;)
Alexis
