[langage C] problème avec les sémaphores

Bonjour!

Dans un TD de cours on est censé créer une bibliothèque permettant la création rapide de mutex/sémaphores. On a eu la correction et pourtant sur mon ordinateur ça ne marche pas je ne sais pas pourquoi.
J'ai montré mes algorithmes à mon professeur il ne comprend pas non plus pourquoi, or j'ai besoin de cette bibliothèque pour un projet...

Pouvez vous m'aider ? :/

Je met mes algorithmes en pièces jointes :
Maintenant je vous explique mon problème : on lance un processus fils, bloqué par un(e) mutex (P(mutex)). Le processus père attend cinq secondes puis incrémente la mutex (V(mutex)).
Donc normalement quand on lance le programme, il ne se passe rien pendant 5 secondes puis le processus fils débloqué affiche "mutex passé" puis le programme se coupe.
Alors que chez moi, il se passe le contraire, le programme affiche directement "mutex passé" puis se ferme après avoir attendu 5 secondes.


Quelqu'un sait il pourquoi ? MOn professeur, avec mes algorithmes arrive à le faire marcher...
J'ai le même problème pour mon projet.

Voilà merci beaucoup si vous vous penchez sur la question!

Misaki

Bonjour,

Il y a plusieurs erreurs dans ton code.

— Sur la forme : il manque les headers #include <sys/ipc.h>, #include <sys/sem.h> et #include <unistd.h> (pour sleep() et fork()) dans ton programme ;

— Sur le fond : tes appels à P et à V peuvent échouer mais tu ne le contrôles pas. Tu aurais dû. Si tu écris :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <string.h> #include <errno.h>   void P(int semid) { int r,e;   r=semop(semid,&sP,1); e=errno;   printf ("P: r=%d errno=%d: %s\n",r,e,r?strerror(e):""); }

---

… tu obtiens :

Code:

---

P: r=-1 errno=13: Permission denied

---

Reste à savoir pourquoi tu n'as pas les autorisations d'écriture dans le sémaphore. Le problème vient de cette ligne-là :

Code:

---

if(cle = ftok("/etc/passwd",0)== -1){

---

La priorité des opérateurs en C nous indique que l'opérateur de comparaison « == » est plus fort que celui d'affectation « = ». Ça signifie que ton programme va d'abord vérifier si la valeur renvoyée par ftok() est égale à « -1 », puis stocker le résultat de cette comparaison dans « cle », donc zéro si c'est faux.

Tu vas donc avoir une variable « cle » toujours nulle dans des conditions d'exécution normales. Or, il se trouve que « 0 » correspond à la valeur de la clé spéciale « IPC_PRIVATE ». Ton appel aux sémaphores va donc réussir quand même et tu vas obtenir un identifiant valide. En principe, tu devrais aussi hériter des droits. Donc, il doit y avoir encore quelque chose de plus qui fasse planter l'affaire, mais peu importe : c'est suffisamment irrégulier pour provoquer des bugs et nécessiter d'être corrigé.

D'autre part, la man page précise que passer « 0 » en second argument de ftok() donne des résultats indéfinis :

Citation:

---

Envoyé par man ftok

De nos jours proj_id est un int, mais seuls huit bits sont utilisés. L'habitude veut que l'on utilise un caractère ASCII comme identifiant de proj_id, ce qui explique pourquoi le comportement est indéfini lorsque proj_id vaut zéro.

---

Si tu utilises GCC et que tu veux programmer avec des options de compilation strictes, insère ceci dans ton fichier ~/.bashrc

Code:

---

alias gcc='gcc -std=c99 -pedantic -W -Wall -Werror'

---

Ceci te donnera la plupart des messages d'erreur et d'avertissement utiles, et considèrera les warnings comme des erreurs, ce qui t'obligera à les corriger d'emblée. Au quotidien, ces options sont suffisamment strictes pour écrire des programmes à peu près propres mais, en entreprise et lorsque l'on travaille collaborativement, il arrive que l'on ajoute en plus un certain nombre d'options, jusqu'à une trentaine, qui ne sont pas prises en charge par -Wall ni -Wextra.

Citation:

---

Envoyé par Obsidian

Le problème vient de cette ligne-là :

Code:

---

if(cle = ftok("/etc/passwd",0)== -1){

---

---

A moins que tu n'aies de serieux problemes d'espace disque (au point de ne pas pouvoir aller a la ligne dans tes codes sources), ce genre de code est tout de meme beaucoup moins maintenable que le code suivant:

Code:

---

1 2 3 4 5

cle = ftok ("/etc/passwd", 0) ; /* attention, ne pas utliser 0, voir post ci-dessus */ if (cle == -1) { /* gestion du soucis */ }

---

Citation:

---

Envoyé par gangsoleil

A moins que tu n'aies de serieux problemes d'espace disque (au point de ne pas pouvoir aller a la ligne dans tes codes sources), ce genre de code est tout de meme beaucoup moins maintenable que le code suivant:

---

Mouais, c'est discutable (et on l'a déjà fait, d'ailleurs). Il y a des règles (tacites ou non) qui ont été édictées en entreprise et qui ont des raisons d'être, mais interdire systématiquement tout ce qui fait la souplesse du C, ça ne me plaît pas beaucoup non plus.

En l'occurrence, l'auto-affectation ne sert peut-être pas à grand chose dans le cas d'un if, mais elle devient très intéressante dans le cas d'un while, où cela nous évite d'avoir à rajouter une instruction supplémentaire en dehors du corps de la boucle uniquement pour l'initialiser.

Citation:

---

Envoyé par Obsidian

Mouais, c'est discutable (et on l'a déjà fait, d'ailleurs). Il y a des règles (tacites ou non) qui ont été édictées en entreprise et qui ont des raisons d'être, mais interdire systématiquement tout ce qui fait la souplesse du C, ça ne me plaît pas beaucoup non plus.

En l'occurrence, l'auto-affectation ne sert peut-être pas à grand chose dans le cas d'un if, mais elle devient très intéressante dans le cas d'un while, où cela nous évite d'avoir à rajouter une instruction supplémentaire en dehors du corps de la boucle uniquement pour l'initialiser.

---

Je ne nie pas l'interet de tout un tas de choses en C, je pense juste que lorsqu'on debute, il est plus simple d'ecrire du code sur plusieurs lignes plutot que de vouloir tout faire sur une ligne et de ne pas etre capable de debugger tout seul.

D'ailleurs, l'utilisation de l'operateur ternaire dans ton printf ne me choque pas.