Discussion :

[SteelBox]

Bonjour, j'ai quelques questions concernant la programmation système sous linux.

1. Lorsque l'on utilise une boite aux lettres :

Code :

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

1
2
3
 
//---Initialisation de la boite aux lettres (ou file des messages)
int messages = msgget(ftok("m",3), IPC_CREAT | 0660);

Quand on fait un appel (bloquant) à msgrcv(). S'il n'y a pas de messages dans la file, le processus se met en attente. Quel est la stratégie adoptée par linux : le processus se met il en sommeil et c'est l'envoi du message qui va le réveiller ou est ce autre chose ?

2. Comment faire pour qu'un processus se mette lui même en sommeil ? comment le réveiller ensuite ?

Merci

[Pouic]

Quand on fait un appel (bloquant) à msgrcv(). S'il n'y a pas de messages dans la file, le processus se met en attente. Quel est la stratégie adoptée par linux : le processus se met il en sommeil et c'est l'envoi du message qui va le réveiller ou est ce autre chose ?

Le processus s'endort sur la ressource. Au moment de l'election d'une nouvelle tache, le systeme va verifier les ressources disponibles, et si celle sur laquelle le process attend est dispo, il est mis a l'etat RUN et attend son election.

2. Comment faire pour qu'un processus se mette lui même en sommeil ? comment le réveiller ensuite ?

Avec les signaux, mais ca risque d'etre tordu à faire pour le reveiller apres

[SteelBox]

Avec les signaux, mais ca risque d'etre tordu à faire pour le reveiller apres Wink

Justement comment fait le processeur si l'on veut la réveiller ?

[Pouic]

Hmm, déja, pour qu'un programme "s'endorme" au niveau systeme, il doit par exemple attendre sur une E/S, ou un mutex/semaphore.
Donc on pourrait envisager le pseudo-code suivant :

Code :

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
 
mutext_t m;
 
void sighandler(int s){
 sem_post(&mutex);
}
 
int main(void){
 
    alarm(10);
    /*  redefinition du traitement associé à sigalrm */
......
   /*  */
   sem_wait(&mutex);
 
   return 0;
}

En gros, ce pourrait etre une idee possible....
Mais de la meme maniere, si tu l'endors avec sleep, ca marchera aussi... Et si tu n'introduis pas la notion de temporisateur, il faut une intervention exterieure (toi ou un autre programme), pour le reveiller (dans le cas d'une combinaison wait(NULL) / reception d'un SIGCHLD, par exemple)

++
Pouic

[SteelBox]

Le processus s'endort sur la ressource. Au moment de l'election d'une nouvelle tache, le systeme va verifier les ressources disponibles, et si celle sur laquelle le process attend est dispo, il est mis a l'etat RUN et attend son election.

J'aimerais être sur de comprendre.
Prenons un exemple. J'ai une tache T1 qui a fait un appel bloquant sur un mutex par exemple. Le jeton n'était pas disponible donc la tâche s'endort sur cet appel bloquant ? Comment averti t-elle le scheduler qu'elle s'est endormi ?

Ensuite, le scheduler ordonnance les différentes tâches. Au bout d'un moment il redonne la main à T1 ? est ce T1 qui lui dit que la ressource n'est pas dispo ou est ce le scheduler qui vérifie si la ressource est dispo et qui ne donne la main à T1 que si la ressource est dispo ? (ceci me semble consommer trop de temps, surtout que le switch doit être rapide...).

Une fois ces questions éclaircit, je pense que ca sera bon pour le reste

Merci

[Pouic]

J'aimerais être sur de comprendre.
Prenons un exemple. J'ai une tache T1 qui a fait un appel bloquant sur un mutex par exemple. Le jeton n'était pas disponible donc la tâche s'endort sur cet appel bloquant ? Comment averti t-elle le scheduler qu'elle s'est endormi ?

Il faut imaginer que lorsque qu'au niveau utilisateur tu fais un read/wait/sem_wait, etc.... , il y a en dessous des fonctions systeme pour coder tout ca : tu n'as que l'interface publique de ces fonctions. Pour le cas du mutex, lorsque tu fais un sem_wait, implicitement, tu appelles (par exemple), la version noyau de sleep, qui prend une adresse de ressource, et une priorite de reveil. C'est elle qui modifie les entrees dans la struct P et/ou U afin de signaler au systeme que ton process s'est endormi sur telle ressource, et qu'il doit avoir telle priorite lorsque la ressource sera disponible.

Ensuite, le scheduler ordonnance les différentes tâches. Au bout d'un moment il redonne la main à T1 ? est ce T1 qui lui dit que la ressource n'est pas dispo ou est ce le scheduler qui vérifie si la ressource est dispo et qui ne donne la main à T1 que si la ressource est dispo ? (ceci me semble consommer trop de temps, surtout que le switch doit être rapide...).

Et pourtant, le "switch" de processus passant sur le processeur est une operation tres lourde : restauration de contexte, etc... En fait, au moment d'elire une nouvelle tache, il y a un parcours des differentes struct systeme, et mise à jour de tout ça (sinon, ton systeme risquerait d'avoir quelques incoherences !). C'est pendant ces mises a jour que le systeme verifie si telle donne est disponible, etc... et agit en consequence (en reinserant le process dans la liste des processus prets alors qu'il etait dans l'etat "SLEEP" par exemple).

++
Pouic

[SteelBox]

Ok, j'ai bien compris la deuxième partie...
Juste un détail sur la première partie :

C'est elle qui modifie les entrees dans la struct P et/ou U afin de signaler au systeme que ton process s'est endormi sur telle ressource, et qu'il doit avoir telle priorite lorsque la ressource sera disponible.

=> donc, la primitive système change le contenu de la structure et appelle le scheduler ? en fait, j'ai du mal à saisir comment se fait ce passage ? il ne faut pas attendre le prochain switch je pense ?

Merci

[Pouic]

=> donc, la primitive système change le contenu de la structure et appelle le scheduler ?

C'est exactement çà

[SteelBox]

Et le scheduler, en temps normal, quand il ne se fait pas appeler par un appel système, il fonctionne avec un timer, un watch dog ?

[Pouic]

Et le scheduler, en temps normal, quand il ne se fait pas appeler par un appel système, il fonctionne avec un timer, un watch dog ?

Ben oui... L'horloge systeme est la pour ca
A tous les tics d'horloge, il se passe plein de trucs ! Ca peut definir la fin d'un quantum de temps pour le processus courant, il faut rearmer l'horloge, faire toutes les maj, recalculer les priorites, etc....

La duree d'un tic est definie par la constante HZ dans param.h (indique le nombre de tics par seconde)
1 quantum = 6 ou 10 tics par exemple