File de message qui se bloque

**saxophtrion** · 26/12/2013, 17h22

Bonjour, je programme une application utilisant les files de message.

Je rencontre un problème, mon application se bloque sur la fonction msgsnd.

Voici comment fonctionne le programme : 4 processus tournent en parallèle

Un processus A remplit les files de message des processus B et C. Jusque là pas de soucis, au bout d'un moment les files de messages des processus B et C sont pleines, donc le processus A se bloque sur msgsnd, je pense que c'est le comportement normal.

Après un premier msgrcv les processus B et C font un sleep d'une ou deux secondes et doivent envoyer le message qu'ils ont reçu de A à D, sauf que le processsus se bloque sur la fonction msgsnd. Je ne comprends pas parce que la file de message du processus D est vide donc il ne devrait y avoir aucun soucis pour l'envoi mais les processus B et C se bloquent bien sur la fonction msgsnd.

Merci de votre aide

**Obsidian** · 26/12/2013, 19h20

Bonsoir,

On suppose que tu travailles sous Linux et que tu utilises les IPC SysV.

Les msgsnd() de B et C bloquent à quel moment ? Dès le premier appel ou après avoir suffisamment tourné pour remplir la file de D ? Est-ce que D lit ses messages ?

**saxophtrion** · 26/12/2013, 19h45

Bonsoir, j'ai oublié de préciser que j'utilisais MAC OS X.

J'ai mis en suspens le processus C pour plus de facilité à comprendre.

En gros A envoie plein de messages à B à la suite. B receptionne mais il y'a un sleep entre chaque reception donc forcément il ne suit pas le rythme et les messages s'accumulent jusqu'à remplir la file de B avant la fin du premier sleep.

Du coup A se bloque ce qui est normal. Ensuite à la fin du sleep B envoie un message à D mais là ça ne passe pas. D est bien en attente d'un message mais ne reçoit jamais rien. Et s'il ne reçoit rien c'est parce que B se bloque lors du msgsnd(). Pourtant la file de D est belle est bien vide.

Le programme fonctionne parfaitement lorsque je change les temps dans les sleep et que je fais en sorte que la file de B ne soit jamais pleine. Or lorsque la file de B est une fois pleine, le msgsnd de B se bloque sans que je comprenne pourquoi. msgsnd() de B semble ne pas passer lorsque la file de B est pleine alors que ça ne devrait avoir aucune incidence ... Car lorsque la file de B n'est pas pleine il n'y a aucun soucis

**Obsidian** · 26/12/2013, 20h27

Peut-on voir ton code ?

**saxophtrion** · 26/12/2013, 20h58

Processus A

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
18
19
20
21
22
23
24
25
26
27
28
29
30
for(int i = 0; i < nbPieces*2; i++){           
 
 
 
        T_message* pieceAEnvoyer = (T_message *)malloc(sizeof(T_message));      
 
 
 
 
 
        sleep(tempsPieces);                            
 
 
 
 
        random = rand()%(1-4) +1;                    
 
 
 
        pieceAEnvoyer->mtype = random;                 
 
 
 
 
 
 
 
            msgsnd (msgB, pieceAEnvoyer, strlen(pieceAEnvoyer->mtext), 0);    
 
        }

Processus B

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 while(entrepotPlein == 0) {
 
        T_message* texte = (T_message *)malloc(sizeof(T_message));
 
 
 
        msgrcv(msgB, texte, 256, 0, 0);
 
sleep(2);
 
            msgsnd(msgD, texte, 256, 0);
 
}

Processus D

Code :

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

1
2
3
4
5
6
7
8
9
10
 for (int i = 0; i < nbPieces*2; i++) {                 
 
        T_message* texte = (T_message *)malloc(sizeof(T_message));     
 
 
        msgrcv(msgD, texte, 256, 0, 0); 
 
printf(...);
 
}

**Metalman** · 27/12/2013, 08h57

On est bien d'accord que tu as mis "quelque part" dans ton code que T_message est composé d'un long et d'un char* ?

Code :

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

1
2
3
4
struct msgbuf {
long mtype; /* type de message, doit être > 0 */
char mtext[1]; /* contenu du message */
};

Ton random a l'air de mettre "au moins" 1... mais n'hésite pas à ajouter des parenthèses en plus...

Code :

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

 random = (rand() % (1 - 4)) + 1;

Il y aurait moyen que tu fasses un autre programme qui affiche l'état de chaque file en parallèle ?

...................
Attend....
Où se trouve ton msgget qui transforme le key en int ?

**saxophtrion** · 27/12/2013, 11h53

Bonjour, je n'ai pas trop envie d'afficher tout le code car c'est un projet et il m'est déjà arrivé quelques problèmes de plagiat lorsque j'ai demandé de l'aide sur le net en postant tout mon code

Je l'ai simplifié mais oui bien entendu j'ai déclaré ma structure elle est bien composée d'un long et d'un char *, je fais bien un ftok et un msgget avant pour déclarer mes files , chacune avec une clé différente.

Le random quant à lui génère bien un nombre entre 1 et 3 il n'y a pas de soucis.

Comme je l'ai dit le programme ne présente aucun soucis lorsque les files n'atteignent jamais leur taille maximum donc je ne vois pas le soucis.

Pour ce qui est de l'affichage d'une liste comment puis-je faire ? Jusqu'à présent j'ai seulement réussi à afficher le nombre de message présent dans chaque file mais je ne sais pas exactement ce que vous entendez par "état" d'une file ?

**Metalman** · 27/12/2013, 11h58

Un msgctl() contenant un IPC_STAT en cmd.... et ça remplira la structure en 3e argument.
Et tu affiches toutes les infos utiles.
Ca "pourrait" servir à vérifier quelle file bloque vraiment...

OU

Tu fais des msgsnd et msgrcv avec IPC_NOWAIT, et tu affiches les perror pour être sûr des erreurs.

Je te conseille de faire les 2 et de voir où bloque quoi exactement.

**saxophtrion** · 27/12/2013, 12h40

J'ai fait ce que vous avez dit, j'ai rajouté les flags NoWait et j'ai affiché les données qui me semblaient importantes.

Lors du blocage voilà ce que j'obtiens :

FILE B : Number bytes queues = 72 Nombre message dans la queue = 40 Maximum number of bytes allowed in queue = 2048

FILE D : Number bytes queues = 0 Nombre message dans la queue = 0 Maximum number of bytes allowed in queue = 2048

J'ai également affiché perror et j'obtiens les deux mêmes erreurs pour l'envoi de message du processus A vers B et de B vers D.

Erreur 1: Resource temporarily unavailable

Lorsque j'utilise les No wait, il y'a une erreur seulement lors du premier envoi de B vers D, la première "pièce" n'est donc pas envoyée à D mais ensuite tout reprend son cours normal, la "pièce" 2 3 4 5 ... sont bien envoyées à D

**Metalman** · 27/12/2013, 13h48

A tout hasard, chaque file utilise un fichier différent ?
J'ai lu quelque part que des collisions existent sur le résultat de ftok... (mais tu nous as assuré qu'elles étaient différentes...)

Et pour la 1ère pièce qui fail en NOWAIT, c'est aussi une "ressource temporarily unavailable" ?

**saxophtrion** · 27/12/2013, 13h57

Oui les fichiers utilisés sont bien différents !

Je mets un perror après chaque msgsnd() tant que A envoie bien à B j'ai une erreur timed out (due à autre chose ? ) et dès que ça se bloque c'est

ressource temporarily unavailable

Que ce soit de A vers B ou de B vers D

**Metalman** · 27/12/2013, 14h11

Eh bien dans ce cas....
Euh....
Bah....
Je ne sais pas...

Malheureusement pour toi j'ai plutôt creusé le sujet voisin : les POSIX MQ... pas trop les SysV MQ !

Je ne peux pas répondre plus... désolé ^^'

**saxophtrion** · 27/12/2013, 14h14

Avec le code en totalité tu penses pouvoir réussir à trouver quelque chose ?

Parce que là c'est en gros ce que je fais mais je ne suis pas à l'abri d'avoir fait des erreurs ailleurs :/

**Obsidian** · 27/12/2013, 15h30

Envoyé par saxophtrion

Avec le code en totalité tu penses pouvoir réussir à trouver quelque chose ?

Oui. C'est forcément la manière dont tu l'ouvres ou le gères qui provoque ces bugs. Mais si on peut en plus les compiler sur d'autres machines (les nôtres), ça permettra aussi de localiser d'éventuels effets de bord.

**Obsidian** · 29/12/2013, 18h10

Hello, je n'ai fait que survoler ton programme mais à aucun moment tu ne testes la valeur de retour de msgsnd, ni celle des autres d'ailleurs.

J'ai donc remplacé tous les msgsnd de ton programme par des my_msgsnd et écrit la fonction correspondante avec les mêmes arguments, pour appeler msgsnd normalement mais faire en plus quelques contrôles.

À aucun moment tes msgsnd ne fonctionnent correctement. À chaque fois, perror("") me renvoie « Invalid argument ». Même chose pour l'initialisation de tes sémaphores. Il a fallu ajouter « 2>&1 | less » pour avoir le début de ta sortie mais celle-ci nous donne :

pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
: Invalid argument
pb avec semop
…

… sur une trentaine de lignes avant de passer à la suite. Si ni tes sémaphores ni tes file de messages sont correctement initialisés, il y a peu de chances pour que ton programme aboutisse…

**saxophtrion** · 29/12/2013, 18h36

Il est vrai que je ne teste à aucun moment la valeur de retour de mes msgsnd. Je les ai affichées pour débugger mais ça m'a juste confirmé que le msgsnd plantait mais malheureusement je n'en sais toujours pas plus. C'est bizarre que les msgsnd ne fonctionnent jamais car chez moi entre les processus, les messages se transfèrent bien comme il faut.

Pour ce qui est de mon programme les erreurs que tu obtiens je ne les ai seulement que lorsque le programme est interrompu à cause d'une erreur et que les sémaphores et files de messages ne sont pas restituées au système. Du coup quand on essaye de créer un sémaphore avec une ID déjà existant ben forcément ça plante. Je les supprime alors à la main dans ce cas.

EDIT : je viens de faire un test, jusqu'au blocage, tous mes msgsnd retournent bien 0

**saxophtrion** · 30/12/2013, 15h21

Alors encore du nouveau, j'ai fait des tests dans tous les sens et il se passe quelque chose de bizarre :

Le processus A s'arrête d'envoyer quand il y'a 40 messages en tout dans les files du processus B et C ... Exemple 22 messages dans la file du proc B et 18 dans la file du proc C.

Lorsque je ne laisse qu'un seul proc tourner, sa file va bien jusque 40 messages avant que A se bloque, j'ai bien changé les temps de traitement des messages pour que les files se vident à des vitesses différents mais les résultats sont toujours les mêmes.

Lorsqu'on additionne le nombre de messages de la file de B et celle de C on obtient toujours 40 ... Y'a t-il quelque chose à régler de spécial ? Parce que là vraiment je vois pas pourquoi tout se bloque à 40

**Metalman** · 30/12/2013, 15h51

Lorsque je ne laisse qu'un seul proc tourner, sa file va bien jusque 40 messages avant que A se bloque

Envoyé par saxophtrion

J'ai fait ce que vous avez dit, j'ai rajouté les flags NoWait et j'ai affiché les données qui me semblaient importantes.

Lors du blocage voilà ce que j'obtiens :

FILE B : Number bytes queues = 72 Nombre message dans la queue = 40 Maximum number of bytes allowed in queue = 2048

Je "pense" qu'il y a eu un malentendu à la création de la file !

**saxophtrion** · 30/12/2013, 16h00

Pourtant je la déclare de cette façon ^^

Code :

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

msgBC = msgget(cleBC, IPC_CREAT | IPC_EXCL | 0666 );

Est-il possible que ça soit quelque chose de configuré par défaut sous mac OS ?

Parce qu'à aucun moment je limite le nombre de message de la file...

**Metalman** · 30/12/2013, 16h08

Nononononon... ^^'

msgget => "get"... ça ne "set" pas !

ftok te donne un identifiant (ID/nom de fichier)
msgget te donne un file descriptor, en gros (FD/ID)

Mais pour "modifier" le comportement de la file, il faut faire un msgctl avec en argument "cmd" un IPC_SET, et remplir correctement al structure avec le nombre max de messages qui t'intéressent (enfin plutôt la taille en octets du coup...).

De ce que je comprends, tu as des problèmes du côté des consommateurs...
Est-ce normal qu'il y ait si peu de consommateurs de la file ?

Obsidian a fait remonter des problèmes de sémaphore, ça devient EVIDENT : tes consommateurs sont bloqués et ne peuvent plus accéder aux files....
Il faudrait bien vérifier tes sémaphores.

File de message qui se bloque

C

Discussions similaires

Partager

Partager