S'il n'y a aucune contention à quoi sert le lock ?
J'ai du mal a comprendre la question. Un lock, c'est pour eviter un acces simultane en ecriture/lecture et eviter une race condition. Les contentions, c'est une question de nombre d'acces et de chance eleve d'avoir le lock deja pris quand on accede a la dite valeur. On peut avoir besoin d'un lock parce que on a une donnee qui est lu une fois lorqu'elle change par frame et qui sera ecrite souvent a la vitesse d'une IO. Mais clairement, cela ne causera pas de probleme de contention.
Je ne sais pas comment marche go pour ça les go routines sont allouées à un thread système et les threads systèmes sont exécuté sur n'importe quel cpu ?
Un pool de thread systeme est cree et matche le nombre de core disponible. Chaque goroutine sera alloue individuellement, aura sa propre stack et sera schedule en fonction des capacites/de la demande sur un thread systeme approprie. Il y a un tres faible controle de la part de l'application sur ou va etre execute une goroutine. Le scheduler essaye de faire de son mieux pour eviter de changer de CPU et enchainer les executions de goroutine pour eviter d'avoir une goroutine bloque sur une autre trop longtemps (L'ecriture dans un channel est souvent le point de logique qui va declencer un changement de goroutine si il y a une goroutine en attente sur le channel en question).
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4. Dernière modification le 06 mars 2022 à 18:56.
J'ai du mal a comprendre la question. Un lock, c'est pour eviter un acces simultane en ecriture/lecture et eviter une race condition. Les contentions, c'est une question de nombre d'acces et de chance eleve d'avoir le lock deja pris quand on accede a la dite valeur. On peut avoir besoin d'un lock parce que on a une donnee qui est lu une fois lorqu'elle change par frame et qui sera ecrite souvent a la vitesse d'une IO. Mais clairement, cela ne causera pas de probleme de contention.
Un pool de thread systeme est cree et matche le nombre de core disponible. Chaque goroutine sera alloue individuellement, aura sa propre stack et sera schedule en fonction des capacites/de la demande sur un thread systeme approprie. Il y a un tres faible controle de la part de l'application sur ou va etre execute une goroutine. Le scheduler essaye de faire de son mieux pour eviter de changer de CPU et enchainer les executions de goroutine pour eviter d'avoir une goroutine bloque sur une autre trop longtemps (L'ecriture dans un channel est souvent le point de logique qui va declencer un changement de goroutine si il y a une goroutine en attente sur le channel en question).
Ca date un peu, mais c'est encore tres vrai un petit tour des limites de go avec pas mal sur le sujet des goroutines : https://tpaschalis.github.io/reaching-the-ceiling-of-single-instance-go/ . Et pour un cas pratique d'optimisation avec go: https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ .