Discussion :

[boboss123]

Bonjour,

Je suis tombé sur cet article qui parle des go routines sans état qui permettent de gérer de la mémoire partagée entre go routines : http://decouvric.cluster013.ovh.net/...re-memory.html

Est-ce que c'est vraiment la bonne pratique à adopter au lieu d'utiliser des mutex ? Pourquoi ? Quels sont les avantages/inconvénients des deux méthodes ?

... a première vue, je ne vois que des inconvénients à utiliser des go routines sans état :
- il faut une go routine en plus pour gérer les channels.
- il y a des copies de données au lieu d'accéder directement à la donnée (donc ça consomme plus de RAM et de temps CPU)

Merci d'avance

[unanonyme]

Bonjour,

il me semble évident que les deux cas
présentés dans cet article ont un état.
Autrement, nous n'aurions pas besoin de ces constructions.

Les mutex et les canaux sont des primitives à utiliser
à bon escient dont les patrons apparaissent interchangeable
mais dont les subtilités d'usage doivent nous alerter.

Par exemple, il ne sera pas possible d'implémenter
un arrêt d'exécution avec un timeout en utilisant
un mutex https://pkg.go.dev/sync#Mutex
Ce cas d'usage sera plus adéquatement implémenté
avec des canaux et une sélection de branches https://go.dev/ref/spec#Select_statements

Il n'y a pas de bonne pratique systématique ici,
il faudra vous fier à votre expérience et à votre intuition.

Veuillez considérer que le passage des valeurs par copie
peut aussi s'effectuer par l'utilisation de pointeurs,
https://go.dev/ref/spec#Pointer_types
réduisant la quantité de donnée copiée puisque
c'est l'adresse du pointeur qui circule.
Ce faisant on perd tout de même la qualité intrinsèque
du partage des responsabilités inhérent à une copie stricte.
C'est souvent la source d'accès de lecture et écriture concurrent
à un même segment de donnée, ce qui est une source
de problème récurrent et fondamental dans ce paradigme.
https://go.dev/doc/articles/race_detector

J'attire aussi votre attention sur le fait que les primitives telles
que les canaux, les tranches ou les tables de hachage sont
des structures légère qui maintiennent un pointeur
interne sur les données stockées en mémoire.

Par exemple, on lira avec attention ce billet de blog
https://go.dev/blog/slices-intro

A slice is a descriptor of an array segment. It consists of a pointer to the array, the length of the segment, and its capacity (the maximum length of the segment).

Ne vous souciez pas du nombre de routines en cours d'exécution
dans votre programme à moins que celui ci ne soit vraiment
très grand, plusieurs centaines de milliers, des millions.
Le système est conçu pour gérer ces cas.
Cela peut être une difficulté lors du débogage ou
du profilage de vos programmes.

La copie de donnée n'est pas obligatoirement synonyme
de ralentissements. Le compilateur optimise le code
et est capable, lorsque cela est possible, de faire transiter
les données via les registres du CPU qui sont extrêmement rapide.
Lorsque la question se pose il faut prendre en considération
l'architecture d'exécution et appliquer les optimisations
nécessaires pour que le compilateur puisse implémenter
le meilleur chemin d'exécution.
Cela signifie qu'il faudra implémenter les bancs de tests de
performances afin de réaliser un audit en continu https://go.dev/blog/pprof
Voir aussi https://go.dev/doc/pgo

Il faudra aussi désassembler le code afin de s'assurer
que le code machine produit réalise ce que l'on attend
de cette optimisation https://go.dev/doc/asm
Par exemple il faudra optimiser l'agencement des
structures de données (struct packing).
Ce sont des techniques très avancées.

Bonne journée.

[boboss123]

Merci pour cette réponse très détaillée