[Sémaphores]Bloquer la lecture pendant l'écriture, problème complexe !

**muad'dib** · 31/05/2007, 16h04

Salut à tous,

Je suis face à un problème, au sens propre du terme (comme un problème de maths), quant à l'utilisation des sémaphores :

J'ai un serveur et 2 clients.
Le serveur héberge un fichier auquel peuvent avoir accès les clients pour en faire une recopie.
Le serveur, à intervalle X, écrit dans le fichier un certain nombre de données.
J'ai donc mis en place un sémaphore permettant de bloquer l'accès au fichier chaque fois que l'un des processus fais une opération dessus (serveur, client 1 ou client 2).

Seulement, ce qu'il faudrait, ce serait :

que lorsque le serveur écrit dans le fichier, les clients n'y aient pas accès
que lorsque l'un des clients lit dans le fichier, que le serveur n'y ait pas accès
que les 2 clients puissent lire le fichier simultanément

J'arrête pas de retourner le problème dans tous les sens mais je n'arrive pas à trouver la solution !!! (utilisation de 2 sémaphores, un de lecture et d'écriture..)

Quelqu'un aurait une idée ?

**souviron34** · 31/05/2007, 16h08

ya un truc que je comprend pas :

tes clients, ils dialoguent avec le serveur, non ????

Ils n'accèdent pas au fichier directement, si ?

**muad'dib** · 31/05/2007, 16h16

Envoyé par souviron34

Ils n'accèdent pas au fichier directement, si ?

En fait, sur mon serveur, j'ai un fork qui est effectué chaque fois qu'un client se connecte, j'envoie ensuite les données via socket. C'est ainsi que je peux bloquer l'accès au fichier grâce aux sémaphores !

**souviron34** · 31/05/2007, 16h27

oui mais c'est donc le clone (fork) de ton serveur qui dialogue avec le client, et donc qui a accès au fichier, c'est bien ça ?

**muad'dib** · 31/05/2007, 16h34

Exactement ! Ce ne sont que les clones sur le serveur qui accèdent au fichier !

**smashy** · 31/05/2007, 16h42

la possibilite de poser des verrous sur les fichiers ne te suffit pas ?

-ecrivain : pose verrou lecture + ecriture

-lecteur : pose verrou en ecriture

**muad'dib** · 31/05/2007, 16h53

Envoyé par smashy

la possibilite de poser des verrous sur les fichiers ne te suffit pas ?

-ecrivain : pose verrou lecture + ecriture

-lecteur : pose verrou en ecriture

Ce n'est pas aussi simple que ça !!!

Je vais par la suite parler des sémaphores comme un feu qui peut être rouge ou vert :

Le processus écrivain écrit dans le fichier, il place donc le sémaphore de lecture au rouge. OK.

Le client cl1 voit que la lecture est impossible. Il attend donc que le sémaphore passe au vert. Idem si cl2 passe, il prend sa place dans la file d'attente du sémaphore.

Le processus écrivain finit d'écrire. Il remet donc le sémaphore de lecture au vert. OK.

LA intervient le problème. Je veux que mes processus lecteurs puissent lire le fichier en même temps. Or, ils ont chacun pris leur tour dans la queue du sémaphore. cl1 va donc lire en premier, placer le feu au rouge et une fois qu'il aura fini, le placer au vert et permettre à cl2 de lire.

Comment faire pour que cl1 et cl2 puissent lire en même temps ???

**souviron34** · 31/05/2007, 16h57

Je ne comprend pas..

Pour la lecture il n'y a pas de problèmes (pas besoin de sémaphore, sauf si tu veux qu'ils ne voient pas les dernières modifs..)

ça n'est que pour l'écriture qu'il ne peut y avoir concurrence....

Si tu ouvres le fichier avec le flag "r", ça marchera même si tu écris dedans avec un autre process...

Si il n'y a qu'un seul process qui peut écrire, je vois pas le problème...

**smashy** · 31/05/2007, 17h00

sous linux, un semaphore est en fait un ensemble de "sous-semaphores". On peut faire atomiquement des operations sur chaqu un des sous elements.

Operation = -incrementer le semaphore
-decrementer le semaphore (bloquant)
-attendre que le compte du semaphore= 0

semaphore = [1 , 0 , 0]; /* 1 nombre max d ecrivain , 0 nombre actuel de lecteur , deuxieme 0 nombre actuel d ecrivain = (droit_ecriture,nb_lecteur,nb_ecrivain)*/

Lecteur : atomiquement {

attendre nb_ecrivain=0
incrementer nb_lecteur

}

ecrivain : atomiquement {

attendre nb_lecteur = 0
incrementer nb_ecrivain
decrementer droit_ecriture

}

**muad'dib** · 31/05/2007, 17h30

Envoyé par souviron34

Pour la lecture il n'y a pas de problèmes (pas besoin de sémaphore, sauf si tu veux qu'ils ne voient pas les dernières modifs..)

Justement je ne veux pas qu'ils puissent aller lire pendant que le fichier est écrit ! Mais je veux également qu'ils puissent lire ensemble en même temps.

Envoyé par smashy

Lecteur : atomiquement {

attendre nb_ecrivain=0
incrementer nb_lecteur

}

ecrivain : atomiquement {

attendre nb_lecteur = 0
incrementer nb_ecrivain
decrementer droit_ecriture

}

Merci pour les explications, mais ici, si lorsqu'un lecteur prend le contrôle du sémaphore, s'il incrémente le nb_lecteur, ça va bloquer l'accès à ce sémaphore à un autre lecteur non ?

**souviron34** · 31/05/2007, 20h27

Envoyé par muad'dib

Justement je ne veux pas qu'ils puissent aller lire pendant que le fichier est écrit ! Mais je veux également qu'ils puissent lire ensemble en même temps.

eh ben à ce compte-là il suffit dans tous les cas d'ouvrir le fichier en écriture ET lecture (a+)..

Si cela réussit, pour les lecteurs, tu re-fermes et ré-ouvre avec juste r

http://www.rt.com/man/fopen.3.html

http://c.developpez.com/cours/bernar...00000000000000

**muad'dib** · 31/05/2007, 21h31

Non ce n'est pas un problème de méthode d'ouverture mais un problème de coordination entre mes processus !

Pour ce qui est de l'accès au fichier, j'ai 3 processus : le processus écrivain ( E ) et 2 processus lecteurs ( L1 et L2 ).

Je veux que lorsque E écrit, L1 et L2 ne puissent pas lire et lorsque L1 ou L2 lit, E attende la fin de lecture pour écrire.

**smashy** · 31/05/2007, 22h45

Envoyé par muad'dib

Merci pour les explications, mais ici, si lorsqu'un lecteur prend le contrôle du sémaphore, s'il incrémente le nb_lecteur, ça va bloquer l'accès à ce sémaphore à un autre lecteur non ?

Non justement, c'est la decrementation qui est bloquante. Quand tu incrementes, tu augmentes le nombre de "resource dispo" (ici y a pas vraimment de resource , c 'est une "derivation" de l usage du compteur ..)

**muad'dib** · 31/05/2007, 23h58

Envoyé par smashy

Non justement, c'est la decrementation qui est bloquante. Quand tu incrementes, tu augmentes le nombre de "resource dispo" (ici y a pas vraimment de resource , c 'est une "derivation" de l usage du compteur ..)

Je crois que je commence à entrevoir la solution... Par exemple, pour mon cas d'usage, je pourrais allouer disons une centaine de ressources disponibles pour les accès en lecture à mon fichier.

Lorsque le processus écrivain veut prendre le contrôle du fichier, il faudrait qu'il puisse occuper les 100 ressources afin qu'aucun autre client ne puisse se connecter. Quand il finit, il libère de nouveau les 100 ressources, ce qui laisse la place aux clients !! Et dans ce cas là tout pourrait se gérer avec un seul sémaphore !

Je crois que je suis dans le vrai dis moi si je me trompe ?

**smashy** · 01/06/2007, 08h30

Non, tu ne te trompes pas, ta solution devrait marcher , mais tu imposes une limite au nombre de lecteur (quoi que ...)

Ce n'est a priori pas un probleme pour ton cas, mais tu limites implicitement aussi le nombre d ecrivain a 1.

De plus, tant qu'il existe un lecteur, l ecrivain n a aucune chance de faire quoi que ce soit (on doit appeler ca la famine, si je ne me trompe (par opposition au dead lock bien plus connu))

comme je l ai dit, tu as trois primitives (comprendre fonctions) possibles sur un semaphore :

-incrementer de X: non bloquant
-decrementer de X: bloquant
-attendre que valeur = 0 : bloquant

Cette troisieme fonction , couplee avec incrementer permet.

-au lecteur de s enregistrer en tant que tel (incrementation qui, cette fois n est limite que par la precision du compteur interne systeme)

-a l ecrivain d attendre qu il n'y ai plus de lecteur (attendre = 0)

**muad'dib** · 01/06/2007, 09h25

Je pense avoir trouvé une solution fonctionnelle, je me suis bien inspiré de tes conseils, je crois même que je fais exactement ce que tu m'as dit mais c'est encore un peu flou dans ma tête, je m'explique !

J'utilise 2 sémaphores : un en lecture seulement pour les lecteurs, un en lecture seulement pour l'écrivain
Chaque processus n'ayant pas accès en écriture sur l'un des sémaphores a accès en écriture sur l'autre sémaphore (J'appellerai le sémaphore sur lequel l'ecrivain a droit d'écriture SEMW et celui sur lequel les lecteurs ont droit d'écriture SEMR)
Lorsque l'ecrivain veut écrire dans le fichier, il prend le controle de SEMW, en plaçant sa valeur à 1
Lorsqu'un processus lecteur veut lire dans le fichier, il regarde avant toute chose si SEMW est libre, signifiant que l'écrivain ne veut pas écrire. S'il n'est pas libre, il se place en position d'attente
Dans le même temps, le processus écrivain, après avoir pris le controle de SEMW, attend que SEMR soit disponible
Une fois que les processus lecteurs ont fini leur lecture, ils décrémentent SEMR de 1, jusqu'au moment oú celui-ci atteint 0, permettant au processus écrivain de prendre contrôle du fichier !!

C'est une sacrée mécanique mais je pense que c'est fonctionnel !! J'utilise le flag SEM_UNDO pour chaque opération au cas oú un de mes process terminerait anormalement. Je fais tourner 1 écrivain et 2 lecteurs sur ma machine depuis un moment et je n'ai eu aucun problème de famine ou autre. C'est dur à expliquer

! Mais je crois que ça va !

N'hésites pas à me dire si tu entrevois une faille dans mon raisonnement ! Merci en tout cas pour ton aide !

**smashy** · 01/06/2007, 09h30

Ca a l air bien comme solution

[Sémaphores]Bloquer la lecture pendant l'écriture, problème complexe !

Réseau C

Discussions similaires

Partager

Partager