sauvegarde d'un contexte, plus precisément d'une adresse a exécuter

**antho_gpz** · 18/09/2014, 09h39

Bonjour, me revoila sur le forum avec un nouveau problème, voila je code un OS temps réel et j'ai un petit soucis pour sauvegarder un "contexte"
j'explique mon cas:
je suis en train d'exécuter une tache i, cette tache requiert a un moment donner un événement qui n'est pas encore arrivé. Donc la tache s'arrète de s'exécuter en plein milieu pour attendre cet événement.
En attendant je réalise d'autre opération ..... lorsque que l'événement arrive pour débloquer la tache 1, je doit retourner précisément à l'endroit ou je me suis arrété.
Comment faire pour enregistrer cette adresse? Assembleur ou C

Je travaille sur PIC32
cordialement

**Médinoc** · 18/09/2014, 09h49

Normalement lors d'une interruption, on empile simplement l'adresse de retour (et tous les autres registres aussi, d'ailleurs, il n'y a pas de "scratch registers" pour les interruptions), non?

**antho_gpz** · 18/09/2014, 10h03

oui sa fonctionne bien pour les interruprions, or la il ne s'agit pas d'une véritable interruption, (exemple timer, interruption externe ...) la c'est le programme qui va par exemple déclarer l'événement débloqué, donc quand le programme aura détecté que l'événement est débloqué, il faudra que le program counter aille à la tache i à l'endroit ou elle c'est arrété
Donc il faut je pense que je sauvegarde l'endroit ou elle s'est arrété pour y retourné après. Mais je ne sais pas comment récuperer l'adresse a exécuter.

Exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
Tache1()
{
   j'exécute des instructions
   . 
   .
   je doit disposer d'un évenement pour continuer, la tache se met en suspend
   je doit reprendre ICI l'exécution de la tache
   .
   .
}

et en attendant l'événement j'exécute d'autres taches.

**Médinoc** · 18/09/2014, 11h09

Ça ressemble tout simplement à deux threads, ça. Et le changement de contexte, qu'il soit ou non à l'initiative du thread, compte comme l'interrompant et doit marcher de manière similaire. Dans ce cas-là, il me semble que la sauvegarde est plutôt dans la structure de données décrivant le thread auprès du kernel plutôt que dans l'une ou l'autre pile, en l'absence d'un besoin de récursion...

**antho_gpz** · 18/09/2014, 11h23

bah en faite oui j'ai décrit pour chaque structure de tache un emplacement pour sauvegarder l'emplacement a reprendre. Enfin je crois que je ne comprend pas ta réponse, désolé

la en faite je souhaiterais arréter la première tache complétement et revenir que plus tard. donc le threads 1 est arréter

**Médinoc** · 18/09/2014, 11h33

C'est typiquement ce qui se passe dans une fonction d'attente.
Cela se passe dans le kernel avec la complicité du scheduler. Une fonction d'attente, une fois passée en kernel-mode, doit:

Régler des informations indiquant quel(s) objet(s) de synchronisation peu(ven)t réveiller le thread.
Marquer le thread comme "en attente" pour que le scheduler ne le re-sélectionne pas.
Contacter le scheduler pour qu'il fasse un changement de contexte maintenant, sans attendre l'expiration de son timer.

Quand le second thread signalera l'objet de synchronisation pour indiquer la fin de sa tâche, cela causera un autre appel kernel-mode, qui changera l'état du premier thread de "en attente" à "prêt à exécuter". Le scheduler fera le reste quand son timer sonnera (ou quand le second thread se terminera complètement, vu que ça aussi, ça cause probablement un changement de contexte anticipé).

**antho_gpz** · 18/09/2014, 13h58

ok je voit ce que tu veut dire, alors j'ai essayé de mettre en attente le premier thread, en attente de l'événement et j'espere que le timer relance de nouvelles interruptions et donc de nouveau la fonction schedule. Or il ne le fait pas. En effet je pense que comme lorsqu'il y a une interruption, la fonction interruption est ouverte et ne peut pas se réouvrir.

voila le code de l'interruption:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
ISR2( iinterruptTIMER2)//routine d'interruption du timer 2, cadencement de l'ordonnanceur
{
        interrupt_TIMER2_flag_off()
        Error = Schedule();
        if(Error != E_OK)//si on a une reeur
        {
            ErrorHook(Error);
            ShutdownOS (Error);
        }
        LancementTache();             
}

et quand je bloque la tache 1, je fait appelle a une fonction qui regarde si l'événement est disponible sinon elle attend qu'il le soit, donc le ISR2 reste ouvert.

Code :

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

1
2
3
        while((EVENT_REG&Mask)==0){/*on attend que l'événement arrive
                                  en attendant des interruptions du timer 2 provoque des ordonancement*/}
        printf("l'evenement reprend, la tache est arrivee\n");

comment puit je faire pour que les interruptions tu timer se déroule normalement?

**Médinoc** · 18/09/2014, 14h21

Normalement, l'attente d'un objet de synchronisation n'est pas censée être active.

**sambia39** · 18/09/2014, 19h32

Bonsoir
Juste une suggestion, si c'est vraiment une restauration de contexte que tu veux en langage C système, pourquoi ne pas utiliser les primitives existant sous UNIX cela te faciliterait la tâche

en utilisant les primitives suivantes setjmp & longjmp dont l'un sauvegarde le contexte actuel et l'autre la restaures tu pourrais très bien réaliser ce que tu veux avec ça ? plus d'avis serait la bienvenue
Exemple plus courant détection d'une division par 0

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
 
#define ALR	1
#define MIN	50
#define MAX	100
 
int i;
int ret;
 
jmp_buf rest_Context;
struct sigaction s_Event;
 
/***
*       Handler
***/
void h_Sig( void ){
 
	printf("#Dectection division par Zéro à la tâche %d\n ", i);
	longjmp( rest_Context, ALR );
}
 
/***
*       Fonctyion divisition
***/
int f_Calcul( int iArg ){
 
	return ( MIN /  ( ( iArg * iArg)  - MAX ) );
}
 
/***
*       Fonction principale
***/
int main( void ){
 
	int iRet = 0;
	(&s_Event)->sa_handler = h_Sig;
	sigaction( SIGFPE, &s_Event, NULL );
 
	for( i = 0; i < MIN/3; i++ ){
 
		iRet = setjmp( rest_Context );
		if( iRet == 0 ){
 
			ret = f_Calcul( i );
			printf("Loop (%d) =\t%d\n", i, ret );
		}
		continue;
	}
 
	return ( 0 );
}

à bientôt

**antho_gpz** · 19/09/2014, 08h27

Alors, j'ai essayé de jouer avec les threads, au début j'étais content car cela marcher avec un seul événement en attente, le problème c'est que si je met un autre événement en attente un autre thread s'ouvre et si je débloque le premier il ne peut pas y revenir, donc il faut vraiment une solution ou je peut sauvegarder le program counter ou la tache s'est arrétéé et y aller quand j'ai envie afin de ne pas ouvrir un grand nombre de threads qui peuvent bloquer mon programme.

Je ne voit pas trop comment je peut utiliser la fonction sjmp, auriez vous d'autres infos?
merci

**Bktero** · 19/09/2014, 08h34

Envoyé par antho_gpz

je code un OS temps réel

Envoyé par sambia39

pourquoi ne pas utiliser les primitives existant sous UNIX cela te faciliterait la tâche

Ca va être difficile d'utiliser des fonctions d'UNIX quand on code un OS...

Mais l'idée est bonne puisque les fonctions sont en fait fournies par les normes C, elles ne sont pas spécifiques UNIX

--> http://linux.die.net/man/3/longjmp
D'ailleurs : http://ww1.microchip.com/downloads/e...User_Guide.pdf --> page 373

**antho_gpz** · 19/09/2014, 09h00

j'ai essayé dans un bout de programme avec mplab et sa compile, sa renvoit bien a la hauteur du Setjmp() donc a voir si j'arrive a me débrouiller avec ça en créant un nouveau buffer pour chaque attente

**antho_gpz** · 24/09/2014, 18h43

bonjour je reviens à vous a cause d'un autre problème lié à setjmp(buf).
La fonction fonctionne bien, sauvegarde bien l'adresse a revenir avec le long jump. Le problème est que lorsque j'appelle la fonction setjump, elle vient m'écraser des valeurs avec un 0. je ne comprend pas du tout car j'ai regarder les adresse et elle ne sont pas les mêmes.

Code :

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

1
2
3
setjmp(OS_TASKS[1].ptr_PC);//mémorisation de l'adresse d'arret
        WaitEvent(Event2);//regarde si l'événement est dispo ou non
        if(OS_TASKS[1].STATE!=RUNNING) return;//si la tache est en waiting on arrête, si la tache est en RUN on continue

voila je vient stocké l'adresse de set jump dans un élément de structure mais le problème c'est que je vient écraser un autre élément plus loin dans la mémoire
OS_TASKS[2].SCHEDULE = 0 , qui est un autre élément de la même structure a un indice près.

j'ai donc regarder les adresses que prend setjmp(buffer)
de 0xA0000374 , avec la valeur stocké du program counter 0x9D008C2C
à 0xA00003D0 , les valeurs sont que des 0
en effet il attribut pour le compilateur xc32 un tableau de 24 pour le buffer

et la valeur qu'il change est a l'adresse 0xA00003FC,

de plus c'est "périodique" si je fait un setjmp(OS_TASKS[2].ptr_PC), il va me modifier la structure de l'indice 3, le même élément.

Comment faire pour éviter cela?

**Médinoc** · 24/09/2014, 19h29

Setjmp n'agit pas que sur le pointeur d'instruction, il agit aussi sur le pointeur de pile. Et pour cela il n'est fiable que pour remonter dans la pile, et peut-être à bas niveau, pour sauter d'une pile à l'autre. En aucun cas il ne doit être utilisé pour retourner dans une fonction qui s'est déjà terminée.

Normalement le changement de contexte d'un thread à l'autre (chaque thread ayant sa propre pile), je pense que c'est le genre de partie d'un OS qu'on code en assembleur. Mais peut-être que dans ce cas précis, un usage judicieux de setjmp() peut suffire...

**antho_gpz** · 25/09/2014, 08h45

oui je pense que le setjmp() je peut oublier ...
Cependant en assembleur je ne sais pas du tout comment avoir accès à la "stack" pour connaitre par exemple le PC de l'instruction suivante.

voila le jeu d'instruction dont je dispose:
http://www.johnloomis.org/microchip/...tructions.html

**Médinoc** · 25/09/2014, 11h56

Ah, là on entre sur un territoire inconnu pour moi, celui des processeurs sans pile... On peut toujours faire des piles bien sûr, mais elles sont alors en software (par exemple, l'opcode le plus proche d'un "jump to subroutine" semble être "jump and link", qui semble mettre l'adresse de retour dans un registre au lieu de l'empiler...).

Il serait intéressant de voir l'assembleur généré par ton compilateur C sur cette plate-forme.

De plus, cette doc ne dit pas vraiment dans quelles circonstances on accède aux registres Shadow...

sauvegarde d'un contexte, plus precisément d'une adresse a exécuter

C

Discussions similaires

Partager

Partager