"Salut, Amigo ! Je veux vous parler du partage des ressources. À travers différents fils, bien sûr.
"Je n'arrête pas de parler des problèmes qui surviennent lorsque vous travaillez avec plusieurs threads et de la façon de les résoudre. Cela ne signifie pas que l'utilisation de threads est mauvaise. Les threads sont un outil très puissant. En fait, ils vous permettent d'accélérer votre programme et même plus fiable. Plus un programme est complexe, plus il comporte de threads et de diverses parties indépendantes.
"Diviser un programme en parties indépendantes (relativement couplées) est très bénéfique."
"Imaginez que votre programme est divisé en 100 threads en interne. Mais vous n'avez qu'un processeur double cœur. Cela signifie qu'en moyenne 50 threads seront exécutés sur chaque cœur."
"Si vous avez besoin d'augmenter les performances du programme, il vous suffit d'acheter un serveur à double processeur et quelques processeurs doux pour cela. Cela pourrait vous donner jusqu'à 32 cœurs, ce qui augmenterait les performances de 2 à 20 fois. Selon le nombre de parties vraiment indépendantes en lesquelles il est divisé. »
"C'est l'une des raisons pour lesquelles Java domine le développement d'entreprise. Si une entreprise a un programme interne complexe écrit par 20 développeurs, il est beaucoup moins cher d'acheter un autre serveur que de doubler les performances du programme grâce à l'optimisation."
"Alors c'est de ça qu'il s'agit."
"Mais ! Chaque fois qu'un développeur décide d'utiliser un autre thread, il résout un problème et en crée deux. De plus en plus de threads n'augmenteront pas indéfiniment les performances du programme."
"Premièrement, tout programme a un travail qui ne peut pas être séparé et exécuté en parallèle sur différents threads. Deuxièmement, tous les threads sont exécutés sur le même processeur. Plus vous avez de threads, plus chacun fonctionne lentement."
"Et, plus important encore, les threads utilisent souvent les mêmes objets (généralement appelés" ressources partagées ")."
"Par exemple, un thread souhaite enregistrer des informations sur le travail qu'il a effectué dans un fichier. S'il existe plusieurs threads de ce type et qu'ils souhaitent écrire des informations dans le même fichier, ils interféreront les uns avec les autres. Pour éviter que le fichier ne devienne un désordre confus, l'accès au fichier est limité, c'est-à-dire pendant qu'un thread utilise le fichier, les autres attendent."
"Oui, je m'en souviens. Vous faites cela en utilisant le mot clé synchronized ."
"Exactement exact."
"Et que se passe-t-il si les threads écrivent dans des fichiers différents ?"
"Formellement, ce sont des objets différents, mais ils sont probablement sur le même disque dur."
"Alors, est-il vraiment possible de paralléliser quelque chose à l'intérieur du processeur ?"
"Techniquement, oui, mais dès que votre fil a besoin de quelque chose en plus des données dont il dispose, ce quelque chose pourrait déjà être occupé par un autre fil - et votre fil devra attendre."
"Eh bien, que dois-je faire alors ? Comment savoir si je dois faire beaucoup de discussions ou non ?"
"Ceci est déterminé directement par l'architecture de votre programme. Chaque projet a son propre 'architecte' qui connaît toutes les 'ressources' utilisées dans le programme, connaît leurs limites et à quel point elles sont bien/mal parallélisées."
« Et si je ne sais pas ?
"Il y a deux options :"
a) travailler sous la supervision de quelqu'un qui
b) obtenir des morceaux pour le comprendre par vous-même
"Je suis un robot : je n'ai pas de grumeaux, seulement des bosses."
"Eh bien, alors, fais des bosses."
"Je vois. Merci. Vous avez clarifié certaines choses sur lesquelles j'avais déjà commencé à me poser des questions."
GO TO FULL VERSION