Questions programmation système

Version imprimable

13/02/2005, 14h17
SteelBox

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

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

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 :D
13/02/2005, 17h18
Pouic

Re: Questions programmation système

Citation:

Envoyé par SteelBox

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.

Citation:

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 ;)
13/02/2005, 19h10
SteelBox

Citation:

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 ?

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:

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

14/02/2005, 23h08
SteelBox

Citation:

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 :D

Merci
14/02/2005, 23h23
Pouic

Citation:

Envoyé par SteelBox

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.

Citation:

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
15/02/2005, 00h22
SteelBox

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

Citation:

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 :D
15/02/2005, 00h31
Pouic

Citation:

Envoyé par SteelBox

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

C'est exactement çà ;)
15/02/2005, 00h53
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 ?
15/02/2005, 01h04
Pouic

Citation:

Envoyé par 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 ?

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