IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau C Discussion :

les fonctions statiques sont-elles réentrantes ?


Sujet :

Réseau C

  1. #1
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2007
    Messages
    630
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2007
    Messages : 630
    Points : 234
    Points
    234
    Par défaut les fonctions statiques sont-elles réentrantes ?
    Bonjour,

    Je développe sur Ubuntu 10.4 dans un environement multithread pour traiter les paquets réseaux. Je compile avec gcc et l'option -O0

    Je définis des fonctions statiques dans maliste.h. Il s'agit de fonctions d'ajout, de parcours (iterator) de paquets dans une vlist. Ces fonctions sont appelées dans differents fichiers.c. Toutes ces fonctions sont intrinsèquement réentrantes (pas de variable globale, pas de variable statique)

    J'ai un problème quand j'appelle deux fois mon iterator sur deux objets complètement differents mais qui se trouvent dans un meme fichier.c. J'ai l'impression que les fonctions ne sont pas vraiment réentrantes. J'ai des pointeurs qui sont corrompus dans mon iterator...

    Ma question:
    une fonction statique ne devrait-elle pas être appelée par deux threads différents sachant que les deux appels sont situés dans un meme fichier.c ?

    Remarque:
    Quand le meme iterator est appelé dans deux fichiers.c différents, ca ne pose pas de problème ...

    Merci d'avance pour votre aide.

  2. #2
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 480
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 480
    Points : 13 677
    Points
    13 677
    Billets dans le blog
    1
    Par défaut
    static ou inline ?

  3. #3
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2007
    Messages
    630
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2007
    Messages : 630
    Points : 234
    Points
    234
    Par défaut
    j'ai oublié un détail très important. Il s'agit de fonctions INLINE static !!!

  4. #4
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 599
    Points
    23 599
    Par défaut
    Bonjour,

    Citation Envoyé par ikuzar Voir le message
    Je définis des fonctions statiques dans maliste.h. Il s'agit de fonctions d'ajout, de parcours (iterator) de paquets dans une vlist. Ces fonctions sont appelées dans differents fichiers.c. Toutes ces fonctions sont intrinsèquement réentrantes (pas de variable globale, pas de variable statique)
    Le propre, en C, d'une fonction statique est de rester interne à son unité de compilation. Comment tes fonctions peuvent-elle être alors appelées depuis d'autres fichiers *.c ? Le sont-elle via d'autres fonctions intermédiaires qui elles servent d'interface ?

    J'ai un problème quand j'appelle deux fois mon iterator sur deux objets complètement differents mais qui se trouvent dans un meme fichier.c. J'ai l'impression que les fonctions ne sont pas vraiment réentrantes. J'ai des pointeurs qui sont corrompus dans mon iterator...
    Difficile de t'en dire plus sans voir le contexte. Corrompus comment ?

    Normalement, statique ou pas, inline ou pas, tu ne devrais avoir aucun problème avec tes variables locales. Par contre, il existe aussi le cas du TLS bien connu avec les threads.

    une fonction statique ne devrait-elle pas être appelée par deux threads différents sachant que les deux appels sont situés dans un meme fichier.c ? Remarque: Quand le meme iterator est appelé dans deux fichiers.c différents, ca ne pose pas de problème ...

    Merci d'avance pour votre aide.
    Bktero a judicieusement mis le doigt sur le bon problème à mon avis : si tu précises « inline » au compilateur C, ce mot-clé peut être interprété de manière différente selon le contexte, et ne reste au final qu'une indication pour le compilateur. En gros, ta fonction déclarée inline le sera effectivement « si le compilateur peut le faire ». Plus précisément, si tu décris une fonction inline et que tu la compiles, puis que tu y fais références depuis d'autres unités de compilation compilées séparéement et à d'autres moments, alors le compilo ne pourra pas intégrer son code au sein de ces autres fonctions : elle redeviendra une fonction ordinaire avec un point d'entrée en mémoire.

    De plus, C99 ramène pudiquement cela à une simple histoire de vitesse d'exécution :

    Citation Envoyé par n1256
    6.7.4 Function specifiers
    Syntax

    1
    function-specifier:
    inline

    […]

    Semantics
    5 A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible.120) The extent to which such suggestions are effective is implementation-defined.121)
    Présenté autrement, si la fonction reste bien interne à son unité de compilation et qu'aucune référence n'est faite à son point d'implantation en mémoire ou quoi que ce soit d'autre mais que, malgré tout, insérer son code partout où on y fait appel reste plus pénalisant qu'en faire une fonction ordinaire, alors elle risque de redevenir également une fonction ordinaire, à la discrétion de l'implémentation du compilateur.

  5. #5
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2008
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 515
    Points : 2 505
    Points
    2 505
    Par défaut
    Il n'y a aucun lien entre la réentrance et le fait que ta fonction soit static (ou inline). Tu fais probablement des choses qui ne sont pas thread safe dans ta fonction.

    Il est possible par contre que le fait que la fonction soit static (ou inline) encourage le compilateur à procéder à certaines optimisations qu'il ne ferait pas autrement, et qui peuvent rendre visible des bugs qui passeraient autrement inaperçus. Par exemple on voit souvent des "volatile" qui manquent pour que du code soit réellement thread safe. Souvent ça ne pose pas de problème, mais si le compilo décide de faire la "mauvaise" optimisation...

  6. #6
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2007
    Messages
    630
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2007
    Messages : 630
    Points : 234
    Points
    234
    Par défaut
    Citation Envoyé par matafan Voir le message
    Il n'y a aucun lien entre la réentrance et le fait que ta fonction soit static (ou inline). Tu fais probablement des choses qui ne sont pas thread safe dans ta fonction.

    Il est possible par contre que le fait que la fonction soit static (ou inline) encourage le compilateur à procéder à certaines optimisations qu'il ne ferait pas autrement, et qui peuvent rendre visible des bugs qui passeraient autrement inaperçus. Par exemple on voit souvent des "volatile" qui manquent pour que du code soit réellement thread safe. Souvent ça ne pose pas de problème, mais si le compilo décide de faire la "mauvaise" optimisation...
    Je compile avec l'option -D_GNU_SOURCE et sans optimisation: -O0.

    Citation Envoyé par Obsidian Voir le message
    Bonjour,
    Le propre, en C, d'une fonction statique est de rester interne à son unité de compilation. Comment tes fonctions peuvent-elle être alors appelées depuis d'autres fichiers *.c ? Le sont-elle via d'autres fonctions intermédiaires qui elles servent d'interface ?
    Il n'y a pas de fonction intermédiaire. Les corps des fonctions inline static sont définis dans maliste.h. Ce fichier d'entête est inclut dans les fichier.c contenant les appels à ces fonctions. Il s'agit de fonctions implementant une liste vectorielle (vlist) et l'iterator qui va avec. la vlist est utilisée pour stocker les paquets. Je les ai définis inline static pour optimiser le temps d'execution.

    Citation Envoyé par Obsidian Voir le message
    Difficile de t'en dire plus sans voir le contexte. Corrompus comment ?
    Je travaille sur Ubuntu 10.04 64 bits. J'ai deux Threads T1 et T2 qui sont lancés à partir de main.c et dont le boulot, grosso modo, c'est de bosser sur des paquets. les fonctions associés à T1 et T2 sont respectivement traiter_paquets_1( ) et traiter_paquets_2( ). Ces deux fonctions se trouvent dans un_meme_fichier.c. Les deux threads NE partagent PAS les même paquets, je fais des copies pour chaque thread. Quand je parcours ma vlist avec un iterator, à un moment donné, je tombe sur un bloc dont l'adresse n'est pas bonne. Apparemment elle ne fait pas 64 bits et provoque un segmentation fault quand j'essaie d'accéder aux champs du bloc comme le montre le debug ci-dessous. (i est un iterator).

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    (gdb) print i->block 
    $1 = (struct block *) 0x7069
    (gdb) print i->block->data 
    Cannot access memory at address 0x7081
    Quand je ne fait pas appel à un iterator de malist.h et que à la place je parcours "à la main" ma liste, je n'ai plus ce problème !

  7. #7
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2008
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 515
    Points : 2 505
    Points
    2 505
    Par défaut
    Je ne vois pas trop ce qu'on peut te dire de plus sans voir le code. Ton iterator est buggé ou n'est pas thread-safe.

    Chaque thread alloue son propre itérateur ?

  8. #8
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2007
    Messages
    630
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2007
    Messages : 630
    Points : 234
    Points
    234
    Par défaut
    Citation Envoyé par matafan Voir le message
    Je ne vois pas trop ce qu'on peut te dire de plus sans voir le code. Ton iterator est buggé ou n'est pas thread-safe.

    Chaque thread alloue son propre itérateur ?
    Oui, chaque thread alloue son propre itérateur.

  9. #9
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par ikuzar Voir le message
    Je compile avec l'option -D_GNU_SOURCE et sans optimisation: -O0.

    Les corps des fonctions inline static sont définis dans maliste.h

    Je les ai définis inline static pour optimiser le temps d'execution.
    Donc si je comprends bien :
    Tu compiles sans aucune optimisation du compilateur, et pour gagner du temps, tu ecris du code dans un fichier d'en-tete que tu inclus partout, et tu esperes que l'ajout des mots-cles "inline static" va t'aider ?

    Et pourquoi ne pas essayer de compiler avec des options d'optimisation ? Certes, il arrive que le compilateur soit buggé, mais c'est tout de meme beaucoup plus rare que les programmes buggés.

    Et si avec ces options tu as des problemes de performance, a ce moment la tu commences a te poser des questions sur l'algorithmique de ton programme.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  10. #10
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2007
    Messages
    630
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2007
    Messages : 630
    Points : 234
    Points
    234
    Par défaut
    Je compile deux fois. En -O0 quand je suis en mode dev puis en mode -O3 en mode test.
    Sinon, le problème est reglé: j'ai un bout de code qui n'était pas thread safe car je déverouillais trop vite la partie du code en question.

    Merci pour toutes vos indications/explications.

  11. #11
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par ikuzar Voir le message
    Sinon, le problème est reglé: j'ai un bout de code qui n'était pas thread safe car je déverouillais trop vite la partie du code en question.
    Et visiblement avec un code dégeulasse, car si tu as du code dans des fichiers .h, et a fortiori du code static, c'est une erreur fondamentale de structuration et de compréhension...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Les normes W3C : sont-elles utiles ?
    Par sachav dans le forum Balisage (X)HTML et validation W3C
    Réponses: 121
    Dernier message: 30/01/2013, 18h17
  2. Les tablettes graphiques sont-elles confortables d'utilisation ?
    Par keokaz dans le forum Périphériques
    Réponses: 8
    Dernier message: 10/03/2009, 21h00
  3. [SSH2] Les fonctions ne sont pas (re)connues
    Par Nikko92 dans le forum Bibliothèques et frameworks
    Réponses: 8
    Dernier message: 14/07/2008, 13h32
  4. Les actions Struts sont-elles multithread
    Par mrjeronimo dans le forum Struts 1
    Réponses: 3
    Dernier message: 20/05/2008, 14h53
  5. Application : Les procedures stockées sont-elles inévitables ?
    Par nytmare dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 19/11/2006, 19h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo