Planete Sciences

Titre racoleur, histoire de tenter un nouvel échange sur le problème de la réentrance .
J’en profite pour remercier les participants au débat sur l’atomicité. Ca a permis d’enrichir ma connaissance et celle de mon équipe, en espérant qu’il en sera de même pour d’autres participants.

La réentrance puisse qu’il s’agit d’elle maintenant se pose pour des fonctions utilisées à la fois dans un programme d’interruption et en dehors de celui-ci. La question est de savoir si une fonction en cours d’exécution peut être interrompue sans risque par elle-même. La encore notre modeste expérience avec des micros 8 bits et divers compilateurs nous a permis de lever quelques lièvres.
Avant même de livrer quelques infos et pour ne pas passer pour maître d’œuvre sur le sujet, j’aimerais connaître la position de certains sur ce nouveau problème.

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Merci à toi GARGAMEL pour remettre un peu d'animation sur le forum.

Avant tout j'aimerais savoir pourquoi vous vous trouvez confrontés à la réentrance.
Autant je peux le comprendre pour des fonctions utilitaires qui peuvent être appelées depuis un programme d'interruption ou depuis le programme principal, autant je ne vois pas trop l'intérêt pour le reste.

Dans le cas d'une fonction utilitaire, c'est relativement simple, il suffit de ne pas écrire dans des variables globales, toutes les autres variables n'étant que des paramètres ou des variables locales. Dans ce cas, le problème de réentrance se réduit à avoir une pile de taille suffisante pour ne pas l'exploser.

Il est donc "facile" de rendre une fonction au sens Pascal réentrante, ce qui est plus compliqué c'est de rendre un programme au sens Pascal réentrant et là, à vrai dire, je n'y vois pas trop d'intérêt, mais je rate peut-être quelque chose.

Je ne veux pas commettre un non sens dans l’interprétation de ce que tu appelles « fonctions utilitaires », c’est pourquoi je précise que nous avons rencontré des problèmes dan le cas de
fonctions de bibliothèque incluses avec le compilateur .
Il se trouve que certaines fonctions fournies ne sont pas réentrantes et c’est à nous de le vérifier. Certaines fonction mathématiques par exemple ne le sont pas (Je parle de compilateurs industriels de bonne réputation). L’un des compilateurs avait la bonne grâce de nous planter à la compilation avec le message d’erreur correspondant. L’autre plus inquiétant laissait passer. Dans les 2 cas il a fallu réagir sur ces fonctions non réentrantes. Les cas classiques que nous avons rencontrés concernaient certaines fonctions trigonométriques qui ne sont pas réentrantes si on prend la peine de lire la documentation fournie. On s’est fait avoir dans les cas ou aucun message d’erreur ou warning n’est apparu à la compilation. A l’époque on ne se souciait pas de l’atomicité et on fonctionnait en asynchrone entre l’interruption par timer et le reste. Ca nous a conduit alors à reécrire la fonction trigo incriminée (En utilisant bêtement des lecture de tableaux prédéfinis), ce qui nous permit de disposer de 2 versions différentes de la fonction.
Normalement avec l’organisation synchrone que nous utilisons maintenant pour régler le problème d’atomicité, le problème ne se pose plus du fait du temps partagé entre l’interruption et les autres fonctions.

Une fonction trigo non réentrante c’est quand même surprenant et je serai intéressé de savoir si vous avez déjà été confronté à ce problème.

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Quelle ne fut pas ma surprise quand je me suis rendu compte que je n'était pas capable d'expliquer quelles étaient les conditions pour qu'une fonction soit réentrante !

Un petit tour sur wikipedia pour se remettre les idées en place : http://fr.wikipedia.org/wiki/R%C3%A9entrance
La page en anglais est plus détaillée, et contient un exemple intéressant : http://en.wikipedia.org/wiki/Reentrancy ... 9#Examples

Dans les liens, il y a cette page d'IBM qui est pas mal faite:

La fonction "strtok" est l'exemple que j'avais en tête. Vu qu'elle garde en interne le restant de la chaîne que l'on veux découper, il n'est pas possible de l'utiliser à plusieurs endroit d'un même programme, et même pire que ça : dans la même fonction mais pour deux chaînes de caractères en même temps (retire un élément de str1 puis un de str2 et on recommence avec str1).

J'imagine que votre fonction de trigo devait utiliser une variable globale ou statique pour des appels récursifs, ce qui fait que si on l'utilise d'un autre endroit, on écrase ces globales/statiques avec le nouveau calcul, et à notre retour on continue de fonctionner sur ces nouvelles données, et pas sur les originales ?

Le lien avec la notion de "thread-safe" est intéressante aussi, lorsque l'on est sur une cible avec un OS.

<warning="troll inside">
En bref : les globales, c'est le mal ! C'est comme les Goto...
</warning>

_________________
Equipe Alpobot : http://alpobot.free.fr

"Puis-je rentrer chez moi si j'y suis déjà ?"

La question mérite d'être posée.
Les deux réponses sont possibles. Oui et non.
Mais la réponse "oui" suppose une maîtrise de la langue et de l'esprit assez fine.

_________________
Chef de projet de l'équipe The Pirate Bot, association GEM6.
http://www.assogem6.sitew.fr/#Accueil.A

C'est exactement ça, pour ces fonction non récursives il y utilisation de variables non pas globales mais statiques. Pour l'autre c'est l'utilisation du errno qui pose problème. Mais je trouve étonnant que ces compilateurs présentent de telles particularités.

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Tu constateras que je ne répond pas par OUI ou NON à la question posée. Donc le doute m'est encore accordé quant à ma maîtrise de la langue, bien que parfois...

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Je pense que dans certains cas ça doit permettre d'optimiser la fonction. Dans le cas d'une fonction récursive, le fait de travailler sur une variable statique évite de la faire passer par les arguments, et donc d'aller charger/décharger la pile.

Cela dis, c'est vrai que c'est assez moyen pour des fonctions de base...

Et puis il faut pas oublier que c'est des gens comme nous qui les codent ces fonctions, donc y'a peut être juste eu de la flemme

_________________
Equipe Alpobot : http://alpobot.free.fr

+1

En fait moi j'ai eu le problème contraire, la fonction fournie était parfaitement réentrante mais m'explosait la pile en prenant 1200 octets dessus alors qu'elle faisait 500 octets. J'ai dû la recoder de manière sale et elle n'était alors plus réentrante, ni lisible d'ailleurs, mais ma pile était sauve.
Ceci pour dire que dans l'embarqué on manque de ressources et ça nous force à faire des compromis.
Ces compromis dépendent du contexte. Donc fournir la bibliothèque parfaite est impossible.
Pour revenir au problème de GARGAMEL, on peut imaginer que l'équipe fournissant la bibliothèque du compilateur s'est dit qu'il y a avait peu de chance d'appeler un sinus dans une interruption, cette fonction étant consommatrice de temps et que, donc, c'est mal de l'appeler dans une interruption (n'est-ce pas GARGAMEL ). Si ne pas la rendre réentrante permettait alors d'économiser de l'espace sur la pile, ils ont fait ce choix.
En embarqué on est en permanence obligé de jongler entre rapidité, taille du programme, réentrance, taille de la pile, lisibilité, ...
Les bonnes bibliothèques contiennent souvent des defines pour indiquer ce qu'on compte privilégier à la compilation.

Merci Gargamel d’animer ce forum avec des sujets techniques.

Pour mon cas je n’ai pas d’expérience en µC 8bits. Mais le problème se pose aussi sur des cibles en apparence beaucoup plus facile à prendre en main : les lego mindstorms !! En NXC (et en RobotC à ce que j’ai pu lire) toutes les fonctions définies par l’utilisateur ne sont pas réentrante même si elles n’utilisent aucune variables globales. Une fonction appelée dans des taches différentes a de bonne chance de vous provoquer des plantages aléatoires. C’est ainsi que l’année dernière j’ai mis une longuuuue semaine à debugger un plantage aléatoire de mon robot. Pour contourner le problème j’ai
- mis en inline les fonctions « courtes »
- j’ai associé à toutes les fonctions pouvant être appelé par deux taches différente une macro préprocesseur qui protège la fonction par un mutex : #define bidulebis(x) acquire(mutex_de_la_fonction_bidule);bidule(x) ;release(mutex_de_la_fonction_bidule);

_________________
ARE (2005 et 2006), AMARE (2010 : 41ème ,2011 : 25ème), MLRobotic (2013)
http://www.mlrobotic.com et http://teamamare.blogspot.fr

Je ne suis que moyennement surpris, à voir selon la plateforme.

J'ai par exemple noté dans le passé, sur PIC18 (avec compilo microchip), que l'utilisation de variables locales (non statiques) dans une fonction, à cause du mode d'adressage un peu pourri des PIC 8 bits, coute bien plus cher en temps d'execution que l'utilisation de variables globales (ou statiques).

Du coup, pour une fonction trigo, à laquelle l'utilisateur de base demandera surtout d'être rapide, cela parait raisonnable d'avoir sacrifié la réentrance pour gagner des perfs.

_________________
Jeune vieux croulant - Moi - I-Grebot - (nos vidéos)

J'ai mal au crâne ...
Je retourne usiner !

_________________
blog : http://olegeurobot2013.blogspot.fr/
2013 - 7ème de la Coupe de Belgique et Prix Spécial du Jury
6ème de la Coupe de France, éliminé en quart de finale par les champions de France et d'Europe
2012 - 6ème de la Coupe de France, éliminé en 8ème

Avant de rentrer dans l'atelier pose-toi la question de savoir si tu n'y étais pas déjà.

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Si l'atelier est bien conçu, il ne pourra pas y entrer avant d'en être sorti !

_________________
Code source de notre robot

Si, c'est possible.

_________________
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr