Discussion :

[eternelNoob]

Bonjour à tous,

je vous expose un peu mon background pour que vous puissiez me situer : je suis un ancien juriste qui passait tellement de temps à coder que j'en ai fait mon métier.
J'ai commencé par le python, puis j'ai fait du C et comme je voulais bosser et que je trouvais le web assez cool, je me suis reconverti dans le développement web.

En ce moment, je suis en train d'apprendre le Rust et j'aime beaucoup le langage en revanche, le fait qu'il soit un peu plus poussé me met en face de mes faiblesses d'autodidacte.

Je suis en train d'apprendre le multithreading, mais plus largement la programmation concurrente et j'ai du mal à saisir la notion de programmation concurrente.

Je sais qu'elle se compose de différentes approches : multithreading, multiprocess et non-blocking I/O qui par ailleurs peuvent être complémentaires entre elles, jusqu'à là, j'ai tout bon ?

Et je vois souvent même dans les forums anglophones que la programmation concurrente est souvent résumée à faire plusieurs choses en même temps :
or si c'est en même temps, certes c'est de la programmation concurrente, mais plus précisément du parallélisme.
Puis je me suis demandé, si je fais un thread::spawn deux fois imaginons, vont-ils nécessairement tourner en parallèle ?
D'ailleurs, quel est l'intérêt du multithreading si ce n'est pas en parallèle ? Ça n'entraîne pas un surcout pour le processeur ?

Imaginons je prends le cas d'un processeur avec un cœur, est-ce que j'y gagne quelque chose à faire du multithreading ?
Dans une pure abstraction, prenons par exemple 1 seconde avec un programme avec deux threads, j'imagine que le processeur va faire thread 1, thread 2, thread 1, thread 2.
Est-ce que ça un vrai intérêt ? D'ailleurs le processeur ne fait-il pas ça avec tous les processus, ce qui donne l'illusion du multitasking ?

Désolé de ce fatras de questions. N'hésitez pas à me demander de reformuler.

[Pyramidev]

Bonjour. Je réponds un peu en retard.

Je sais qu'elle se compose de différentes approches : multithreading, multiprocess et non-blocking I/O qui par ailleurs peuvent être complémentaires entre elles, jusqu'à là, j'ai tout bon ?

Oui.

On peut exécuter plusieurs processus en parallèle.
Dans un processus, on peut avoir plusieurs threads gérés par l'OS.
Avec le non-blocking I/O, on peut avoir plusieurs tâches dans un seul thread ou plusieurs threads.

Le non-blocking I/O est très utilisé dans le web backend. On a souvent des tâches de la forme :

1. Recevoir une requête HTTP, la convertir en requête SQL et envoyer cette dernière à la base de données.
2. Attendre que la base de données réponde.
3. Convertir la réponse de la base de données en réponse HTTP et renvoyer cette dernière.

À l'étape où on attend que la base de données réponde, ce serait dommage de ne rien faire, donc il est opportun d'exécuter une autre tâche en attendant.

Ces tâches sont parfois appelées green threads. Contrairement aux threads normaux gérés par l'OS qui sont plus lents à manipuler, les green threads sont directement gérés par le langage de programmation.

Et je vois souvent même dans les forums anglophones que la programmation concurrente est souvent résumée à faire plusieurs choses en même temps :
or si c'est en même temps, certes c'est de la programmation concurrente, mais plus précisément du parallélisme.

Oui, il y a alors à la fois de la programmation concurrente et du parallélisme.

Mais il existe aussi du parallélisme sans programmation concurrente, notamment quand un processeur exécute des instructions : https://fr.wikipedia.org/wiki/Pipeli...s_processeurs)

Ce cas particulier n'est pas de la programmation concurrente, car le processeur donne l'illusion d'exécuter les instructions dans l'ordre. Le parallélisme est alors une optimisation.

Puis je me suis demandé, si je fais un thread::spawn deux fois imaginons, vont-ils nécessairement tourner en parallèle ?

Pas nécessairement. L'OS fait ce qu'il veut. La machine sera de toute façon limitée par le nombre de cœurs.

D'ailleurs, quel est l'intérêt du multithreading si ce n'est pas en parallèle ? Ça n'entraîne pas un surcout pour le processeur ?

Oui. Du coup, il faut limiter le nombre de threads.

Imaginons je prends le cas d'un processeur avec un cœur, est-ce que j'y gagne quelque chose à faire du multithreading ?
Dans une pure abstraction, prenons par exemple 1 seconde avec un programme avec deux threads, j'imagine que le processeur va faire thread 1, thread 2, thread 1, thread 2.
Est-ce que ça un vrai intérêt ?

S'il n'y a qu'un seul cœur alors, dans la plupart des programmes, le multithreading n'est intéressant que si un thread a besoin d'attendre lors de certaines étapes.

D'ailleurs le processeur ne fait-il pas ça avec tous les processus, ce qui donne l'illusion du multitasking ?

Oui. Par exemple, sur un PC, quand l'utilisateur commence à copier un gros dossier d'un endroit A à un endroit B puis, alors que la copie est en cours, commence à copier un deuxième gros dossier d'un endroit C à un endroit D, cela ralentit la première copie.

[eternelNoob]

Bonjour,

Merci de m'avoir accordé ce temps pour me répondre !
J'ai remarqué que c'est un sujet très courant mais également mal compris même j'ai ceux qui pensent le maîtriser.
Assez content qu'après mes différentes lectures sur le sujet, je ne suis pas complètement paumé.

Je lis et relis l'article sur les pipelines.
L'analogie avec une chaîne de montage aide vraiment à visualiser.
Si j'ai bien compris le concept de pipeline, je pourrais donc avoir deux processus différents que mon processeur gère simultanément car ils sont à des stades de traitement différents.
J'imagine que sur un plan hardware, certains circuits sont distincts et permettent donc d'être gérés de façon autonome ?

Dans ce cas qu'est-ce qui distingue le parallélisme hors du cadre de la programmation concurrente et le parallélisme dans le cadre de la programmation concurrente ?
Peut-être que dans la programmation concurrente, il y a une forme de mutualisation des ressources ?

Merci encore Pyramidev

[Pyramidev]

Je ne connais pas très bien la partie hardware donc je ne saurais pas répondre plus précisément dessus.

Concernant la différence entre le parallélisme et la programmation concurrente, je vais citer deux extraits de Wikipédia, puis je vais préciser comment je les interprète.

Extrait de la page Concurrent computing de Wikipédia :
« The concept of concurrent computing is frequently confused with the related but distinct concept of parallel computing, although both can be described as "multiple processes executing during the same period of time". In parallel computing, execution occurs at the same physical instant: for example, on separate processors of a multi-processor machine, with the goal of speeding up computations—parallel computing is impossible on a (one-core) single processor, as only one computation can occur at any instant (during any single clock cycle). By contrast, concurrent computing consists of process lifetimes overlapping, but execution need not happen at the same instant. The goal here is to model processes in the outside world that happen concurrently, such as multiple clients accessing a server at the same time. Structuring software systems as composed of multiple concurrent, communicating parts can be useful for tackling complexity, regardless of whether the parts can be executed in parallel. »

Extrait de la page Parallel computing de Wikipédia :
« Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency, and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU). In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution. »

La programmation concurrente, c'est quand celui qui programme gère explicitement des tâches entremêlées dans le temps.

Par exemple, si une tâche A écrit dans une variable V et qu'une autre tâche B qui s'exécute à côté lit cette variable V, le programmeur doit faire attention que le comportement de B sera différent selon que A aura déjà eu le temps de modifier V avant que B ne lise V. En plus, dans mon exemple, V doit être protégée par un mutex.

Il faut aussi faire attention à l'accès des ressources en dehors de la mémoire du programme. Par exemple, si une tâche parcourt un dossier pendant qu'une autre y ajoute ou y supprime des fichiers, cela peut partir en vrille.

Quand ces tâches sont exécutées vraiment en même temps, il y a en plus parallélisme.

Le parallélisme sans programmation concurrente, c'est quand celui qui programme n'a pas à se soucier de cette temporalité. S'il programme dans un langage impératif, alors il peut partir du principe que le programme se comporte exactement comme si tout s'exécutait dans l'ordre. Sous le capot, peut-être que plusieurs instructions sont exécutées en parallèle pour optimiser, mais tout se comporte comme si ces instructions étaient exécutées dans l'ordre.

[eternelNoob]

Désolé je réponds avec du retard !

Merci beaucoup, parmi la pléthore de ressources, j'ai complètement oublié wikipédia qui en parle très bien.

Les choses me paraissent beaucoup plus claires, ça me paraît être un topic vraiment avancé.