bonjours à tous les horlogers et autres mécaniciens virtuels,

je me pose la question qui est l'origine de plantages intempestifs.
depuis même les systemes "vax" en passant par unix, les developpeurs de logiciels ne parviennent jamais à empêcher tous les cas de plantage inhérents aux décalages entre la donnée attendue et la donnée disponible.

alors j'aimerais savoir, aujourd'hui , comment on élabore un programme complexe faisant intervenir d'innombrables routines parallèlisées et interdépendantes en données?

j'ai ma petite idée, mais peut-être elle est vieillote et inappropriée, alors j'attend de lire vos réponses éclairées , afin de voir si c'est encore à propos...



-Phil - patient

...
je suis patient mais il y a des limites!
je risque de finir par exposer mon idée!!! (avant même que vous n'ayez dégainer!)



Phil

Hola,

J'avais pas vu ce sujet.

Pour moi l'algorithmique temps-réel est une discipline aussi exacte que la medecine, les problèmes qui peuvent apparaitre m'ont fait perdre quelques litres de sueur...

La gestion du multi-taches est gérée en général comme ceci :
- un noyau possède des fonctions (dites primitives) qui sont liées au planning des taches, aux entrées et aux sortie de façon à ne pas avoir à ré-inventer la roue à chaque fois.
- le systeme d'exploitation qui est un programme qui gravite autour du noyau (en utilisant les fonctions qui tourne en permanence
- des taches (thread in english) qui sont des petits morceaux de programmes qui appellent les fonctions du noyau. Une tache peut etre lancée par le systeme d'exploitation. Cette tache peut redonner la main au systeme d'exploitation qui peut la redonner à une autre tache. Il y a des taches qui sont plus ou moins prioritaires.
le temps du processeur est donc synchronisé comme un planning pour chaque tache.

Le probleme qui fait mal c'est quand deux taches ont acces à la meme zone mémoire. Si une écrit, il ne faut pas que l'autre lise, sinon c'est le bordel.
Il y a pleins de solutions techniques mais le principe est toujours le meme : l'exclusion mutuelle. Pour ecrire dans la memoire, on prend une cle, et on rentre, on fait ses petites affaires. Si une autre tache veut rentrer, elle est bloquée et attend que l'autre rende la clé avant de rentrer à son tour. Ainsi, la zone mémoire a un accès propre.

Ces pauses dans les taches sont gérées par des sémaphores. Ce sont des compteurs que l'on incremente ou decremente à chaque passage. S'il est egal à -1, on s'arrete.

Voila, je suis pas informaticien pur (plutot microinformaticien assembleur power !!!) je pense que certaines personnes peuvent corriger ou compléter.

merci Thot !

c'est super interessant comme début.
alors avec ça, avant de donner une nouvelle idée de roue toute nouvelle, il faut maintenant que je comprenne si elle n'est pas déjà incluse dans les principes utilisés que tu décrits. çàa me donne la direction pour me documenter.

sinon, pour faire court, ce qui me chagrine au premier abord, c'est la forme séquentielle des accès. ça plombe tous les objectifs de performance pure , ça.
mais il me reste à voir à quel niveau que ça se passe.
parce que pour moi il est évident qu'il faut laisser entrer plusieurs personnes dans une meme maison au meme moment, mais en revanche , il ne faut pas laisser plusieurs personnes manger le meme petit morceau de pain en meme temps, ou bien saisir la meme bouteille. donc il y a certaines regles à bien verifier.

il me semble avoir eu plusieurs idées mais j'ai du en perdre quelques unes depuis..
en voici une:
je pensais à installer un systeme d' "energie temporelle" ou bien comme tu le designe déjà peut etre, un droit de priorité sous un certain format.
mais qui pour moi, donne un droit d'accès à un traitement continu du processeur, mais tres limité en temps ou en nombre de cycles...(on voit ici un certain aspect quantique..)
cela constituerais une quotité minimale indivisible de traitement. ensuite plus on attribut de quotité à un processus , et plus il peut faire tourner le processeur pour son compte perso. au bout de cette quotité épuisée, le processus se met simplement en standby avec une memorisation exacte de tous les pointeurs et autre adressage, données temporaires etc..
et des qu'il a de nouveau un peu d'energie , hop! il se remet dans la file d'attente pour avoir sa ration de traitement processeur.


Phil

Très bon résumé Thot !

Pour ceux qui aimerait en savoir plus je vous invite à lire cet article sur le système d'exploitation...

Vous y retrouverez notamment des explications sur :
- les composantes du système d'exploitation
- les systèmes multitâches
- les systèmes multi-processeurs
- les systèmes embarqués
- les systèmes temps réel


@Phil

Ta description me fait penser à un noyau de système d'exploitation (ou kernel). Est-ce que cela correspond ?

Hop, je rebondis sur ce sujet fort interessant!

Phil, effectivement, ce que tu décris, c'est exactement le fonctionnement de nos systèmes d'exploitation moderne (windows, linux, etc.). On donne à chacune des tâches (les threads) un temps d'exécution, qui varie selon la priorité du thread. Si tu veux exécuter une tâche peu importante, tu peux abaisser son niveau de priorité (commande "nice" sous linux, je la connais pas sous windows mais elle existe à coup sur). Si tu as besoin d'une tâche temps réel (enfin... quasi temps réel, tant que l'OS n'est pas spécifique pour ça), tu augmentes la priorité. Le gestionaire de tâche de l'OS se charge du reste!

Le modèle multitâche pose un problème, celui que tu pointe dans ton premier post. L'accès concurrent à une donnée peut être source de bugs et de crashs. Il y a des méthodes pour arbitrer tout ça (une gestion de file d'attente sur un accès mémoire, ou un verrou, etc.), mais c'est vrai que c'est pas évident à manipuler. C'est pour ça que beaucoup de robot suivent le modèle de la quasi totalité des jeux vidéos : ils sont monotâche! Une boucle principale, qui tourne à l'infini, exécute à tour de rôle les fonctions du robot: récupération de données des capteur, analyse, décision, action (par exemple).

Pour faire du multitâche sans se casser la tête en debugging,on peut suivre un principe nommé "programmation orienté composant". Il s'agit de délimiter son programme en blocs, qui sont chacun executés dans un thread séparé, et qui se parlent par l'intermédiaire de queue de message (ou boite au lettre). L'un des avantages, c'est que les blocs (ou composant) peuvent être "débranchés" / "rebranchés", bref c'est très modulaire et dynamique. C'est plus ou moins le modèle que j'ai suivi dans mon projet (enfin j'ai adapté ce qui me plaisait pas :p )


Voila j'espère que vous vous êtes pas endormi pendant la lecture de ce post un peu théorique

Hadrien

Et moi j'en profites pour rebondir sur le principe de "programmation orienté composant" !!! On est parti sur ce mode de travail pour le soft de base de l'asso !
Ainsi chacun pourrait bosser de son côté sur des parties qui le bottent et partagait avec les autres des composants sous forme de dll.

salut ,

en verité je n'ai pas encore ingurgité la réponse de miguil au sujet des OS.
mais c'est super ça , si on va dans cette direction.
je bidouillait en programmation pendant une douzaine d'années avec hypertalk sur mac(une variante de smalltalk je crois)
langage orienté objet , mais avec fonctionnement par agents , ou acteurs, je ne sais pas trop le jargon . ça fonctionnait comme tu le dis, hadrien.
mais il faudrait un truc comme ça qui ne coince pas dans les rouages d'un systeme d'exploitation corrompu. parfois les limites qui font s'arracher les cheveux de programmeur proviennent des defauts de l'infrastructure! (pour ne pas dire souvent) , j'ai toujours été confronté aux p*t*ns de restrictions , et perdu beaucoup de temps avec ça, moi...

mon avis est le suivant:
-soit on programme comme si de rien était et c'est l'environnement de programmation qui fait tout (avec les finesses offertent par l'environnement, le systeme pour lequel c'est prévu, etc...)
dans un premier temps , ça debute toujours comme ça de toute façon.

-soit on prévoit un principe de fonctionnement propre à notre architecture logicielle,
afin de reguler le timing et les echanges et de permettre un partage multiprocessing adapté aux performances attendues spécifiques à l'IA. ça nous permettrait de faire abstraction des defauts des environnements connexes. par exemple la limite du nombre de threads, ou la consommation de puissance inutile de thread non chargés..etc...
mais ça necessite d'elaborer le principe et les petits outils qui vont avec. (peut etre une librairie, sans plus)
à terme, je pencherais pour cette optique là. mais ça parait difficile à vous lire.
je me demande si les gros logiciels de calcul de structure qui procedent comme cela ont leur propre fonctionnement independant de l'OS...?
si c'est le cas, il y a certainement du partage "free" de ressources quelque part dans ce bas monde..

phil.
PS/ ce sujet n'est qu'un debut de reflexion pour l'avenir...au cas ou..

J'ai une autre idée si ça peut servir, car moi je n'y connais rien en multitâche hein^^
Le premier principe qui nous vient lorsque on veut un multitâche c'est que ce soit un vrai multitâche et non un sériel de tâches, aussi le système doit pouvoir autoriser toutes les tâches à lire la même données, même si une autre tâche est en train d'écrire dessus.
Comment arriver à ça ?
Simplement dés qu'une tâche Z demande une opération d'écriture sur une donnée, celle-ci est copiée dans un buffer réservé pour la tâche Z, la donnée est modifiée dans le buffer par la tâche Z, mais les autres tâches peuvent continuer de lire la donnée dans son emplacement d'origine.
Dés qu'il n'y a plus de lectures de la donnée en cours, la tâche Z en profite pour copier son buffer réservé vers l'emplacement de la donnée d'origine ce qui écrase celle-ci avec sa nouvelle valeur.

C'est une proposition, je ne sais pas si cela est applicable en pratique hein