Threading, Multiprocessing & SQLite

Citation:

---

Envoyé par fred1599

Aussi le GIL est une partie importante à ne pas prendre à la légère, on a pas un vrai parallélisme, car un seul thread à la fois sera utilisé sur le processus, ce qui veut dire qu'on pourrait complexifier en ajoutant des modules tels que multiprocessing par exemple.
Malgré le fait que le GIL n'affecte pas autant les tâches qui sont I/O bound, c'est un point que l'on ne devrait pas négliger.

---

hu? avec asyncio, chaque activité s'exécute l'une après l'autre. On n'a pas de parallélisme mais la garantie que le bout de code qui s'exécute est le seul à changer l'état global du programme. Avec le threading, on ne sait pas quand l'activité sera interrompue, et on est obligé de verrouiller certaines partie de code pour s'assurer de la cohérence de l'état. Avec le multiprocessing, c'est encore autre chose: sauf à utiliser de la mémoire partagée sur des types simples, ce sont des messages qui passent entre les processus: on sait ce qui est partagé et ce qui ne l'est pas.
Le GIL n'apporte pas grand chose là dedans: il limite la capacité utilisable à un CPU.
On peut éventuellement utiliser des structures de bases comme les listes au lieu de Queue pour échanger des données entre les threads (certaines opérations étant sérialisées par le GIL, pas la peine d'ajouter des verrous par dessus)... mais comme on ne contrôle pas trop ce que fait et fera le GIL, c'est dangereux pour la maintenance du code.

Citation:

---

Envoyé par fred1599

Dans la complexité des tâches asynchrones qui sont faut avouer, plus sur la partie apprentissage, on pourrait aussi dire que les threads peuvent être complexes sur leur gestion (problème de concurrences).

---

Si on peut organiser le boulot en pipeline avec des unités workables qui passent d'une file d'attente à l'autre après certains traitements, il n'est pas utile d'avoir autant de threads que d'unités de traitement... et au lieu d'avoir une seule file d'attente et des découpages sur les IO (mais pas que) comme le propose asyncio, on aura plus de flexibilité.

La différence est que dans un cas, il faut se prendre le chou pour faire le design de la solution asynchrone alors qu'avec asyncio on aura un truc prêt à l'emploi... mais on se retrouve toujours avec des files d'attentes à vider.

note: quand les threads n'existaient pas, on faisait ce genre de design avec select comme cheville ouvrière pour ordonnancer les traitements (et beaucoup plus de design pour fabriquer des abstractions qui pouvaient s’accommoder du caractère assez primitif de select).

- W

Citation:

---

Envoyé par wiztricks

hu? avec asyncio, chaque activité s'exécute l'une après l'autre. On n'a pas de parallélisme mais la garantie que le bout de code qui s'exécute est le seul à changer l'état global du programme. Avec le threading, on ne sait pas quand l'activité sera interrompue, et on est obligé de verrouiller certaines partie de code pour s'assurer de la cohérence de l'état. Avec le multiprocessing, c'est encore autre chose: sauf à utiliser de la mémoire partagée sur des types simples, ce sont des messages qui passent entre les processus: on sait ce qui est partagé et ce qui ne l'est pas.
Le GIL n'apporte pas grand chose là dedans: il limite la capacité utilisable à un CPU.
On peut éventuellement utiliser des structures de bases comme les listes au lieu de Queue pour échanger des données entre les threads (certaines opérations étant sérialisées par le GIL, pas la peine d'ajouter des verrous par dessus)... mais comme on ne contrôle pas trop ce que fait et fera le GIL, c'est dangereux pour la maintenance du code.

---

Je ne vois pas de contradiction avec ce que j'ai dis précédemment ou peut-être que je ne comprend pas où tu souhaites en venir.
et pour le GIL, je spécifie volontairement ceci,

Citation:

---

Malgré le fait que le GIL n'affecte pas autant les tâches qui sont I/O bound

---

Citation:

---

Envoyé par wiztricks

Si on peut organiser le boulot en pipeline avec des unités workables qui passent d'une file d'attente à l'autre après certains traitements, il n'est pas utile d'avoir autant de threads que d'unités de traitement... et au lieu d'avoir une seule file d'attente et des découpages sur les IO (mais pas que) comme le propose asyncio, on aura plus de flexibilité.

La différence est que dans un cas, il faut se prendre le chou pour faire le design de la solution asynchrone alors qu'avec asyncio on aura un truc prêt à l'emploi... mais on se retrouve toujours avec des files d'attentes à vider.

note: quand les threads n'existaient pas, on faisait ce genre de design avec select comme cheville ouvrière pour ordonnancer les traitements (et beaucoup plus de design pour fabriquer des abstractions qui pouvaient s’accommoder du caractère assez primitif de select).

---

On peut conclure qu'il n'y a pas de réponse unique et que le choix entre les deux approches méritent d'être testées par le PO.

Citation:

---

Envoyé par fred1599

Je ne vois pas de contradiction avec ce que j'ai dis précédemment ou peut-être que je ne comprend pas où tu souhaites en venir.

---

Le point est "Aussi le GIL est une partie importante à ne pas prendre à la légère, on a pas un vrai parallélisme".
Le problème avec le parallélisme est dans l'atomicité de certaines opérations qui ne pourra être réalisée qu'avec des sections critiques (peut importe la forme qu'elles prennent).
asyncio (comme les GUI) c'est coopératif: à l'instant t, un callback sera appelée et le callback suivant attendra sa sortie. Mais contrairement à un GUI où les sections critiques sont implicites (puisque c'est par design), la granularité est trop fine pour se passer de sections critiques explicites (avec asyncio, le callback n'est pas la "fonction").
On se retrouve avec les mêmes ennuis qu'avec threads et multiprocessing.

Le GIL ne change rien à cela. Il interdit juste de profiter de la capacité de plusieurs CPU, on ne pourra consommer qu'un CPU ou équivalent. (chose qu'asyncio ne fait pas non plus - et ce n'est pas son but).... que le parallélisme soit "vrai" ou pas ne change pas grand chose sur les précautions qu'il faut prendre.

- W

Hello,

@wiztricks,

Je comprends où tu veux en venir, sur le fait que le GIL ne change pas les fondements de la programmation concurrente et parallèle.

Bonjour

Je lis avec intérêt, tout en ne comprenant pas toutes les subtilités techniques du GIL. Je peux cependant témoigner, pour l'avoir utilisé de nombreuses fois, que le calcul parallèle exploitant les CPU multicores fonctionne très bien. Avec quelques exemples, on montre facilement qu'avec un tel CPU avec 4 cœurs et l'option processus (ProcessPoolExecutor) du module concurrent.futures, on divise par au moins 3 le temps de calcul. Cela n'est pas vrai, bien sûr, avec les threads.

Merci pour les réponses.
Bon, j'ai testé dans un premier temps uniquement via python et au bout de quelques heures, le script ou le GPIO ne répond plus aux interruptions (peut être un bug que j'ai loupé).

J'ai commencé à presque arrêter de faire ma feignasse pour une version C (pour la détection des interruptions) en faisant mon dev (c) google + system("python") pour avoir quelque chose de presque fonctionnel. Cela a fonctionné un premier temps, puis au re-lancement du programme pour une raison inconnue, plus de détection des interruptions. Il faut que j'explore, savoir si c'est le raspberry qui déconne, mon programme, l'appel des int ou les trois.

(oui c'est sale ^^)

----------

Pour préciser, j'écris à chaque int, dans 2 tables, une de log et une de data, ce qui représente pas grand chose (100o/table environ)

Citation:

---

Envoyé par _Froggy_

Il faut que j'explore, savoir si c'est le raspberry qui déconne, mon programme, l'appel des int ou les trois.

---

Si le programme doit tourner en permanence, il devrait pouvoir sauvegarder des informations sur son état dans un journal, histoire de comprendre ce qui s'est passé après coup.... puis éventuellement essayer de redémarrer.

En fait, lire des données et les écrire, est la partie la plus facile...

- W

Bon, pour conclure :D

J'ai testé :
Programme en C :
La gestion d'interruption

Programme en python (appel via system("python script.py &") pour du pseudo multithread pour feiniasse) :
La récupération des données
L'écriture direct dans la bdd

Lors de stress test (une int toutes les 100ms), j'avais des problèmes d'accès à la bdd, ce qui est logique puisqu'il pouvait y avoir plusieurs accès en même temps et la SD n'est pas ultra rapide et un CPU > 30% sur les process python.

Là, j'ai refais tout en C (quelle merde pour concat des strings + int !) avec buffer d'écriture, je me retrouve à 3% du CPU.

J'avais peur que la librairie wiringPi gère de la pseudo interruption comme en python, mais au final les int sont gérées même quand le programme est en pause. Cela ne semble pas le cas de toutes les librairies de gestion d'int sur GPIO. Certaines semblent juste faire une boucle de détection. Ce qui fait que je n'ai pas besoin de multithread pour l'instant.

Voilou, il faut que je test avec une int toutes les 20ms, mais j'ai pas encore fait le matos ^^

(j'ai passé en résolu même si cela ne l'ai pas pour du python)