Discussion :

[ikuzar]

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.

[Bktero]

static ou inline ?

[ikuzar]

j'ai oublié un détail très important. Il s'agit de fonctions INLINE static !!!

[matafan]

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...

[ikuzar]

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.

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.

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 !

[matafan]

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 ?

[gangsoleil]

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.

[Obsidian]

Bonjour,

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 :

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.