Discussion :

[Thor Tillas]

Bonjour tout le monde,

Je m'excuse pour la longueur du post... les questions se trouvent à la fin... c'est juste pour expliquer sur quoi je travaille

Je suis actuellement en train de développer une applic qui n'a pas le droit d'utiliser les threads. Je sais que ca peut paraître débile, mais dans le cadre de travail, c'est tout à fait justifier. Les superordinateurs sont fait pour calculer des données utilisateur et pas pour perdre leur temps à faire du switch de contexte entre deux threads qui tourne.
Donc les développeurs des langages et des OS ne permettent pas à un programme de lancer un nouveau thread.

Ce que nous avons décidé (moi, mon collègue et notre responsable de projet) de poll le réseau (et oui on doit s'occuper du réseau en plus) uniquement lorsque l'on a la main... évident vous me direz.

Donc mon applic récup des données sur le réseau et en fonction de ca lance des méthodes sur un objet. Nous faisons donc un poll de réseau à chaque fois qu'une méthode de l'objet se termine et à chaque fois qu'il tente d'accéder à une variable sensible (vive les mutex et les sémaphores).

On savons quand il accède à une variable sensible lorsqu'il fait l'appel à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mutex.lock()

qu'il doit ensuite libérer par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mutex.unlock()

Notre problème devient alors comment assurer qu'il n'y aie pas de deadlock en faisant des appels en cascade.
Ex de deadlock :
La première method fait un lock(cond1). Cette condition a été locker préalablement par une autre fonction qui est a présent terminée. Comme c'est un lock bloquant, on poll le réseau et on prend la suivante.
Cette deuxième methode fait un lock(cond2) qui est une condition elle aussi lockée préalablement par une autre méthode alors terminée. Comme c'est un lock bloquant, on poll le réseau et on prend la méthode suivante dans la file d'attente.
par chance cette méthod fait un unlock(cond1) puis retourne.

On retombe alors dans la deuxième méthode qui attend sur cond2.

Si c'est la première méthode qui fait un unlock(cond2) juste après sa section critique cond1, on obtient un joli deadlock d'ou il est impossible de sortir.

La seule solution que nous avons trouvé ou en tout cas imaginé avec mon collègue c'est d'implémenter une mini gestion de contexte nous permettant de faire du switching de contexte et ainsi relancer la première méthode sans que la deuxième ne se soit terminée.

D'ou mes questions :
- Est ce que quelqu'un a déjà essayé de faire du switching de contexte et pourrais nous donner des pistes de où chercher ?
-Est ce que c'est à ce point compliquer pour que personne n'en parle ?
- Est ce que quelqu'un connait une bonne doc sur le sujet ? (je sais google est mon ami... ben pas vraiment en fait... parce que ca fait une bonne heure que je cherche et à part des définitions de "switching contexte" y a pas grand chose)
-Est ce que quelqu'un à un début d'idée génial permettant d'éviter le switching ?
-Est ce que je ferais mieux de me pendre tout de suite ?
-Est ce que quelqu'un a compris ce post vraiment pas clair ?

Voilà... euh.. toutes les réponses sont bienvenues évidemment...

Je vous remercie déjà pour avoir lu et je vous remercie d'avance pour vos réponses...

[olive_le_malin]

Bonjour,

désolé mais moi je n'ai pas bien compris l'architecture du système.
Peux tu la donner sous forme de dessin ou grafcet ?

Est-ce que tu as droit a certaines librairies ?
Si tu peux utiliser les MFC, tu peux utiliser la classe CSingleLock() et IsLocked() qui teste si la ressource est déjà lockée.

mais je pense, en tout cas pour ce qui me concerne, qu'un petit schéma serait le bienvenu ...

@+

[loufoque]

J'ai rien compris mais c'est peut-être ça que tu veux ?
http://libstream.sourceforge.net/index_c.html

[Thor Tillas]

Ok, merci pour vos réponses... Je suis désolé de ne pas avoir pu être très clair... Mais tout a été annulé... Enfin, voici quand meme quelques explications et aussi un début de solution pour faire du switching de contexte... si jamais quelqu'un en aurait besoin un jour...

Pour répondre à la question de l'architecture... ben c'est pas trop trop compliqué... en fait ca ressemble à du RMI pour ceux qui connaissent. On est du côté object distant et l'on doit s'occuper de récupérer des paquets réseaux qui contiennent les appels sur l'objet distant. En gros on a un client qui nous envoie les appels sur les méthodes de l'objet distant et nous on s'occupe de les récup et de les executer.
Tout cela se passait avec des threads auparavant. Mais ce programme doit pouvoir tourner sur des superordinateur qui eux ne supporte pas les thread. Nous devons donc supprimer l'utilisation des threads et faire en sorte que tout tiennent dans un processus (thread).

Je sais pas si c'est plus clair... en gros c'est ca :

.........................Client.....................Network...............broker......................object
...GetNumber()....|..........................................................|................................|.....
-------------------->|...........................................................|................................|
............................|---------------[GetNumber()]----------->|................................|
............................|...........................................................|--GetNumber()----->|

Nous, on s'occupe de la partie broker. voilà...

le pire c'est que ce problème n'existe plus puisque l'on vient de recevoir un mail du développeur précédent qui nous avertis que le lock et unlock sur des sémaphores doivent impérativement se faire dans la même méthode..

Donc notre problème disparaît de lui même...

Mais voici quand même une solution possible si quelqu'un doit un jour implémenter un switching de contexte. Cette solution se base sur le fait que vous êtes sur linux et que votre programme doit tourner dans un seul thread (processus).

Il existe une librarie nommée pth (sous licence GNU) qui est une implementation de thread non-préamptif. En fait, cette librarie permet de créer des "pht Thread" et de choisir lequel doit à présent s'exécuter. Comme c'est du non-préamptif, on ne peut changer le thread en cours d'éxecution uniquement lorsque le thread en cours est terminé ou lorsqu'il se met en attente.

Cette librairie permet donc de créer des contextes adapter à nos besoins et s'occupe de gérer le switching de contexte.

ATTENTION : Elle possède un gros désavantage. Si on la compile avec la librarie pthread, une segmentation fault apparait lors du lancement du pth thread. Il faut donc supprimer totalement l'utilisation des pthread dans l'application avant de pouvoir utiliser les pth.

Voilà j'espère que c'est assez clair pour être utilisé par quelqu'un.

Merci de vos réponses... malgré le fait que cette partie du projet a été annulée...

[loufoque]

Il existe une librarie nommée pth (sous licence GNU) qui est une implementation de thread non-préamptif. En fait, cette librarie permet de créer des "pht Thread" et de choisir lequel doit à présent s'exécuter. Comme c'est du non-préamptif, on ne peut changer le thread en cours d'éxecution uniquement lorsque le thread en cours est terminé ou lorsqu'il se met en attente.

Cette librairie permet donc de créer des contextes adapter à nos besoins et s'occupe de gérer le switching de contexte.

C'est la même chose que ce que je t'ai proposé, sauf que ma proposition a une vraie interface de coroutines et est en C++ (et donc gère aussi les exceptions) alors que GNU Pth est une fausse interface de threads en C.

[Thor Tillas]

ok j'avais pas fait le rapporchement...

Merci pour l'info... si le problème revient à l'ordre du jour j'étudierais plus profondément le lien...