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