Variable globale en C

Bonjour,

Il s'agit d'un petit programme en C que je fais tourner sur ma Raspberry Pi. Rien de bien utile, je m'amuse simplement à faire clignoter des LEDs Dans ce programme, j'ai dû utiliser une variable globale. Je sais ce n'est pas dérangeant, mais du moment que cette pratique n'est pas forcément recommandable, je me demandais s'il n'y avait pas une autre façon de procéder. Après tout, je fais également cela pour apprendre (tout en ayant un projet amusant )

Le programme permet de faire clignoter des LEDs à une certaine fréquence. Fréquence qui est réglée par un client qui se connecte, via le système de socket, au "serveur" : la Raspberry Pi.

Voici le fonctionnement général :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

void server() {
    // Crée le socket etc
    // [...] 
    // Crée un thread qui va exécuter la fonction (appelons la led() par exemple) faisant clignoter les LEDs 
    // [...]
    while( (csock = accept(sock, (sockaddr *) &csin, &crecsize)) ) {
        // [...]
        recv(csock, buffer, 32, 0);
        ledDataHandler(buffer);
    }
}

Il est important de créer un thread pour faire clignoter les LEDs, car la fonction ne peut se permettre d'attendre de recevoir des données (tels que la fréquence de clignotement). Ensuite, je me contente d'envoyer les données reçues à la fonction qui va s'occuper de traiter ces données.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

    // Ma variable globale (structure contenant la fréquence de chaque LED).
    LEDS leds = {0}

    void * led(void *pVoid) {
        // S'occupe de faire clignoter les LEDs
    }

    void ledDataHandler(char *data) {
        // Modifie la variable leds en fonction du paramètre data.
    }

Ici, j'ai la fonction led() qui va lire les fréquences contenues dans la variable leds. Et ledDataHandler() qui va modifier ces fréquences en fonction des donnés reçues par le serveur.

J'ai pensé à créer la variable leds dans la fonction du serveur puis passer sa référence aux deux fonctions mais… Je ne trouve pas cela très pratique. En plus, je ne trouve pas cela logique de créer ma variable leds dans la fonction qui reçoit les informations du serveur.

Je pourrai également traiter directement les données dans la fonction leds mais étant donné qu'il y a une boucle, ce traitement se ferait à chaque itération… Même quand les données ne changent pas.

Est ce que vous voyez une autre façon de procéder ?

Merci

En soit les variables globales sont certes déconseillées, mais parfois elles sont presque indispensables ou très utiles. Typiquement, s'il y a une variable / structure de donnée que tu utilises dans tout le code, le mettre en global n'est pas forcément une mauvaise idée. Mais il faut faire attention aux effets de bord et bien peser le pour et le contre.

Concernant ton cas, je n'arrive pas à identifier en quoi ta variable globale est si importante pour un cas d'usage aussi élémentaire. Pire, de ce que tu racontes, tu as l'air de créer des threads avec cette variable globale partagée : si tu ne mets pas de mutexs pour protéger sa lecture et son écriture, tu t'exposes à des incohérences et conflits dans l'exploitation des données.

Hello

Merci d'avoir répondu.

Concernant ton cas, je n'arrive pas à identifier en quoi ta variable globale est si importante pour un cas d'usage aussi élémentaire.

Oui, il y a sans doute une alternative valable. Mais je ne la vois pas L'autre idée que j'ai en tête, c'est transmettre la variable de la fonction qui gère le serveur à celles qui gèrent les LEDs, comme cela :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

void server() {
    [...]
    LEDS leds = {0};

    // Crée le thread qui va gérer les LEDS
    pthread_t ledThread;
    pthread_create( &ledThread , NULL ,  led , (void *) &leds);

    // On attend que quelqu'un se connecte
    while( (csock = accept(sock, (sockaddr *) &csin, &crecsize)) ) {
        // Lance le gestionnaire de connexion
        connectionHandler(csock, &leds);
    }
}

int connectionHandler(int sock, LEDS *leds) {
    [...]
    // Attend les messages du client
    while ((read_size = recv(sock, buffer, 32, 0)) != 0) {
        [...]
        // Lance le gestionnaire des LEDs
        ledDataHandler(buffer, leds);
    }
}

1
2
3
4
5
6
7
8
9

void * led(void *pVoid) {
    LEDS *leds = (LEDS *) pVoid;
    // Lit les fréquences des LEDs et les fait clignoter
    [...]
}

void ledDataHandler(char *data, LEDS *leds) {
    // Modifie la variable leds en fonction des données...
}

La variable passe de fonction en fonction… Ce n'est pas très pratique non ?

si tu ne mets pas de mutexs pour protéger sa lecture et son écriture, tu t'exposes à des incohérences et conflits dans l'exploitation des données.

Oui bien sûr, j'ai volontairement simplifié le code que j'ai posté

Mon post peut sembler un peu inutile, mais si je poste ce n'est pas pour avoir un programme qui fonctionne. J'essaye plutôt d'apprendre à faire mieux

Tu pourrais utiliser une variable static déclarée dans une fonction.

1
2
3
4
5

int *get_var(void) {
  static int var;

  return &var;
}

Dans chaque fonction où tu as besoin d'utiliser ta variable, tu utilises get_var(); C'est une solution…

Ah oui, bonne idée ! J'avais encore jamais vu cette méthode, merci

Salut.

Nan mais ça reste une variable globale, y'a juste du sucre syntaxique collé dessus.

C'est pas une question d'être pratique, c'est une question de bonnes pratiques. Une variable globale, c'est de l'autorité ambiante : avec une variable globale, une fonction peut accéder librement à des choses hors de la « bulle » des éléments qu'elle a créé ou qu'on lui a donné en paramètre, et ça c'est mal.

• Ça bousille le raisonnement local. Si quelque chose peut être modifié ailleurs sans préavis, ça complique énormément la logique du programme, que ce soit pour le programmeur qui le lit ou pour faire de la preuve formelle ;
• Ça empêche la réutilisation de code, car on utilise un élément précis et pas un autre, au lieu d'un élément choisi par l'appelant. Dans le même genre, ça empêche la paramétrisation. On pourrait préférer qu'une fonction utilise un élément passé en paramètre qui réponde à des critères précis plutôt qu'un élément imposé (exemple typique : un système de logging) ;
• Il faut regarder le code source pour savoir quels sont les éléments utilisés, alors qu'avec des paramètres de fonction c'est auto documenté ;
• C'est souvent révélateur de mauvaise conception (« Allez je fous une globale pour éviter de réfléchir ») ;
• Ça créé des risques de data race dans un environnement concurrent.

Bref, ne fais pas ça, il y a toujours une solution alternative. Ici, je te conseille de rester en monothread, avec une structure de ce genre :

1
2
3
4
5
6
7

tant que ...
  si nouvelles données réseau
    lire données réseau
    mettre les LEDs à jour
  fin si
  clignoter
fin tant que

Si tu veux vraiment rester en multithread, tu devrais séparer complètement le réseau et les LEDs et transmettre les données réseau au thread LED via un canal thread-safe (une simple file SPSC est suffisante ici). Le thread réseau enverrait les données reçues au thread LEDs, qui vérifierait périodiquement les messages envoyés par le thread réseau, mettrait à jour les LEDs et les ferait clignoter.

Je dirais plutôt qu'une donnée utilisée dans plusieurs fonctions/classes/acteurs/whatever n'ayant pas la même responsabilité est un signe flagrant d'erreur de conception. Il n'y a aucune raison qui justifie que des modules indépendants utilisent obligatoirement la même donnée sans que l'appelant n'ait son mot à dire, pour les raisons évoquées au dessus.

Bref, ne fais pas ça, il y a toujours une solution alternative.

[…]

Je dirais plutôt qu'une donnée utilisée dans plusieurs fonctions/classes/acteurs/whatever n'ayant pas la même responsabilité est un signe flagrant d'erreur de conception. Il n'y a aucune raison qui justifie que des modules indépendants utilisent obligatoirement la même donnée sans que l'appelant n'ait son mot à dire, pour les raisons évoquées au dessus.

Mouais, je ne sais pas dans quoi tu programmes dans la vie, mais personnellement quand j'entends des trucs « il faut toujours faire comme ça », « il y a toujours moyen d'éviter ceci ou cela ». Non, c'est faux. Je t'assure, programme au niveau noyau voire bibliothèques élémentaires et tu verras que les variables globales sont utilisées et à bon escient, soit parce qu'il est impossible de faire autrement (sisi, cela arrive), soit la complexité ajoutée est telle que tu perds tout le bénéfice du concept.

D'ailleurs, dès que tu fais des programmes parallélisé tu auras des données partagés avec probablement des mutexs globaux pour les protéger. C'est parfois difficiles ou impossible de faire sans.

Après, je ne le nie pas, ici, ce n'est pas indispensable et ce genre de chose est à éviter au maximum. Mais il y en a des situations où l'appliquer n'est pas un mal en soit…

Utiliser des variables globales n'est pas forcément une mauvaise idée, surtout lorsque l'on parle de programmation concurrente. Néanmoins, comme cela a déjà été dit précédemment, ce n'est pas forcément hyper-propre, et ça tourne vite au vinaigre si on ne maîtrise pas ce que l'on fait.

La norme POSIX propose malgré tout une alternative à cette solution "bricolée" : la mémoire partagée (shared memory dans la langue de Shakespeare). Je ne vais pas faire un cours ici, mais je t'invite à aller jeter un œil à la documentation à ce propos.

Salut,

Ouais, je pense qu'il ne faut pas abuser non plus… Je rappelle quand même la mise en situation de l'auteur :

Il n'est pas en train de mettre au point une bibliothèque ou de réaliser des calculs de hautes précisions, il s'agit de faire fonctionner une LED. Alors, d'accord, l'abus de variables globales nuit à la santé (mentale) des programmeurs, mais bon, j'ai envie de dire qu'ici, on s'en fout un peu.

Mouais, je ne sais pas dans quoi tu programmes dans la vie, mais personnellement quand j'entends des trucs « il faut toujours faire comme ça », « il y a toujours moyen d'éviter ceci ou cela ». Non, c'est faux. Je t'assure, programme au niveau noyau voire bibliothèques élémentaires et tu verras que les variables globales sont utilisées et à bon escient, soit parce qu'il est impossible de faire autrement (sisi, cela arrive), soit la complexité ajoutée est telle que tu perds tout le bénéfice du concept.

Oui, mais ce sont des cas extrêmes loin de représenter la majorité. Une fois un certain niveau d'abstraction dépassé, les variables globales ne sont absolument pas nécessaires, à condition de respecter le principe de responsabilité unique. D'ailleurs, les langages sans globales s'en sortent très bien.

Mais je suis d'accord, toujours est une exagération.

D'ailleurs, dès que tu fais des programmes parallélisé tu auras des données partagés avec probablement des mutexs globaux pour les protéger. C'est parfois difficiles ou impossible de faire sans.

Je dirais au contraire que les globales sont encore plus à proscrire dans un programme concurrent. Avoir des globales protégées par des mutexes globaux, c'est le meilleur moyen pour se retrouver avec des goulots d'étranglement et des risques de deadlock un peu partout. L'idéal est de séparer entièrement les unités parallèles, qui communiqueraient par des files de messages (dont les implémentations canoniques sont lock-free dans tous les cas, et wait-free dans les meilleurs cas). Le meilleur exemple pour illustrer ça est l'actor model.

Il n'est pas en train de mettre au point une bibliothèque ou de réaliser des calculs de hautes précisions, il s'agit de faire fonctionner une LED. Alors, d'accord, l'abus de variables globales nuit à la santé (mentale) des programmeurs, mais bon, j'ai envie de dire qu'ici, on s'en fout un peu.

Certes, mais autant prendre les bonnes habitudes tout de suite sur les cas simples.

Je dirais au contraire que les globales sont encore plus à proscrire dans un programme concurrent. Avoir des globales protégées par des mutexes globaux, c'est le meilleur moyen pour se retrouver avec des goulots d'étranglement et des risques de deadlock un peu partout. L'idéal est de séparer entièrement les unités parallèles, qui communiqueraient par des files de messages (dont les implémentations canoniques sont lock-free dans tous les cas, et wait-free dans les meilleurs cas). Le meilleur exemple pour illustrer ça est l'actor model.

Comme je te le dis, parfois, tu n'as pas vraiment le choix. Bien entendu qu'en règle général, il y a moyen de s'en passer, et heureusement.

Déjà entendu parler de réseaux de Petri ? C'est un excellent moyen de faire des démonstrations sur les programmes concurrents.

Alors, c'était un excellent moyen. On a établit d'autres techniques entre temps (dieu merci).

Merci pour vos réponses

Si tu veux vraiment rester en multithread, tu devrais séparer complètement le réseau et les LEDs et transmettre les données réseau au thread LED via un canal thread-safe (une simple file SPSC est suffisante ici). Le thread réseau enverrait les données reçues au thread LEDs, qui vérifierait périodiquement les messages envoyés par le thread réseau, mettrait à jour les LEDs et les ferait clignoter.

Je pense essayer le monothread et le multithread, je pourrai ensuite comparer J'ai l'intention de faire évoluer le projet, en remplacent notamment les LEDs par des moteurs. Je trouve également intéressant de rajouter un petit accéléromètre pour voir le déplacement effectué. Je devrai recevoir le Raspberry Pi Sense HAT dans quelques semaines Intuitivement, je dirai que plus je peux faire d’itération, plus la valeur de l’accéléromètre sera précise (reste à voir s'il n'y a pas une limitation matériel). Donc si je peux éviter de vérifier à chaque itération si j'ai reçu des nouvelles données, ça pourrait aider. Après il faut également voir quelles ressources sont utilisés en parallèle par la fonction recv() dans un autre thread J'avoue n'avoir aucune expérience là dedans, donc je peux être complètement à coté, mais cela reste intéressant d'essayer toutes sortes d'alternatives Bon je m'éloigne un peu du sujet principal… Je vais déjà essayer d'avoir un code potable à ce stade. Par contre, je n'avais encore jamais entendu parler de "file SPSC" J'ai fait quelques recherches, mais j'ai l'impression de rien trouver de précis. Tu aurais un lien vers un bon article (en anglais c'est bon) ?

La norme POSIX propose malgré tout une alternative à cette solution "bricolée" : la mémoire partagée (shared memory dans la langue de Shakespeare). Je ne vais pas faire un cours ici, mais je t'invite à aller jeter un œil à la documentation à ce propos.

Je n'ai pas le temps de regarder ça ce soir, mais je vais voir dans les prochains jours. Merci

Certes, mais autant prendre les bonnes habitudes tout de suite sur les cas simples.

Oui Je compte par la suite faire des études dans l'informatique, donc si je tombe sur un cas similaire je saurai tout de suite quoi faire, et je pourrai me concentrer sur autre chose

Oui, bon, si les programmes de mon école étaient à jour, ça se saurait depuis le temps.

Quelles méthodes, par exemple, je dois avouer que ça m'intéresse, et que ça reste dans le thème du thread.

C'est pas les méthodes qui manquent, rien qu'avec les triplets de Hoare, pour ne citer que le plus connu, on va avoir : celle qu'a énoncé Hoare en 1976, la concurrent separation logic, le rely-guarantee, et les dérivées de ces machins là, sans compter la tripotée de trucs moins connus. Après on va avoir également les techniques de linéarisation, le bounded model-checking, de l'interprétation abstraite pour les programmes parallèles, les logiques temporelles et notamment la temporal logic of actions de Lamport.

J'ai une liste longue comme le bras de papiers fondateurs de différentes techniques majeures pour la preuve de programmes parallèles et je suis loin d'avoir tout lu.

Merci beaucoup pour les liens, et le code que tu as envoyé

J'ai brièvement essayé le code : tout fonctionne. Maintenant, il ne me reste plus qu'à le comprendre

Cela faisait un moment que je voulais m'intéresser aux variables atomiques, mais je devais à jour gcc (par défaut il y a gcc 4.8 sur Ubuntu) Voilà qui est désormais fait, et je vais m'y mettre dès ce week-end