semaphores V(sem) et P(sem)

Bonjour

J'ai une simple question peut-être triviale (en langage C et "théorie" de la gestion des processus et sémaphores):
J'aurais pu mettre du code semget, semctl,...

Que ce soit pour un simple sémaphore file SEM ou un sémaphore MUTEX :

- L'opération V(SEM) ou V(MUTEX) peut elle être "exécuter/appeler" avant P(SEM) ou P(MUTEX) ?
- Que ce soit "théorique" ou en langage C ?

Je demande ceci pour comprendre dans un exo que le programme principal ne peut pas être celui qui commence par une opération V(sem) ou V(mutex)?


Merci d'avance

Bonjour,

En général, quand une ressource est accessible depuis plusieurs threads, un thread qui veut utiliser la ressource la "réserve" (ex : blocage de mutex, P sur sémaphore ou attente de réception d'un signal), puis l'utilise, puis la libère (ex : déblocage de mutex, V sur sémaphore ou envoi de signal à un autre thread pour dire que ce dernier peut utiliser la ressource).

Mais il existe des cas où la "réservation" et la libération d'une même ressource se font dans des threads séparés.
Par exemple, si on implémente le problème des producteurs et des consommateurs avec des sémaphores, on a un sémaphore fillCount qui représente le nombre d'emplacement occupés dans un tampon, un autre sémaphore emptyCount qui représente le nombre d'emplacements libres de ce tampon et un mutex qui permet de modifier le tampon.
Un producteur qui ajoute quelque chose dans le tampon fait successivement P(emptyCount), Bloquer(mutex), AjouterQch(), Debloquer(mutex) puis V(fillCount). Au final, il a réservé de la ressource "nombre d'emplacements vides" et a libéré de la ressource "nombre d'emplacements pleins".
Un consommateur qui enlève quelque chose dans le tampon fait successivement P(fillCount), Bloquer(mutex), RetirerQch(), Debloquer(mutex) puis V(emptyCount). Au final, il a réservé de la ressource "nombre d'emplacements pleins" et a libéré de la ressource "nombre d'emplacements vides".
Ainsi, quand le tampon est plein, les producteurs se bloquent avec P(emptyCount) et les consommateurs les débloquent avec V(emptyCount). Quand le tampon est vide, les consommateurs se bloquent avec P(fillCount) et les producteurs les débloquent avec V(fillCount).

Pour répondre à ta question, oui, on peut avoir un V appelé avant un P sur la même ressource. Dans mon exemple, on peut avoir V(fillCount) qui est appelé par un producteur puis P(filCount) qui est appelé par un consommateur.

oui un V(sem) peut être appelé avant un P(sem) mais je connais aussi l'exemple producteur-consommateur

mais ma question la plus importante est que même si le tampon est plein ou vide.
un V(sem) doit être précédé d'un P(sem) ce qui permet de savoir où le programme ou la procédure appelante est principale.
Est ce correct de raisonner ainsi ?
ex:
Si le tampon est plein alors la procedure producteur est la principale à regarder dans un exo et inversement si le tampon est vide.
Maintenant cela me pose un problème nouveau de savoir si on est dans un cas producteur-consommateur et un cas lecteurs-redacteur.

Comment identifier les deux cas, les deux situations quand un exo est un peu alambiqué utiliserait des termes différents ?

Citation:

---

Envoyé par Pyramidev

un mutex qui permet de modifier le tampon.

---

En quoi il modifie le tampon déjà ? Parcequ'il se met lui même en file d'attente alors qu'il vaut 1 ou -1 c'est cela ?

ok pour les V appelé avant mais si je reprend l'exemple producteur/consommateurs.
Si le processus producteur ne dépose rien AU DEPART le programme s'arrête là ! Le consommateur n'a rien à retirer.

Donc pour moi, même dans le modèle célèbre producteur/consommateurs ; le producteur reste le processus du programme principal !

Et donc dans un exo ou une situation réel plus complexe, voir où est le processus de procédures, fonctions, programme(s) qui execute tout sémaphore qui amorce le programme en premier me parait primordial.
Avant de se lancer dans une lecture linéaire, itératif des procedures,fonctions, exec prog, etc...

Je me trompe totalement ?

A propos de la question du "processus du programme principal", peut-on voir l'énoncé de l'exo ?
Si l'exo donne le code complet, il faut voir dans le code comment les threads sont lancés pour savoir quelles tâches sont réalisées dans le thread principal et lesquelles sont réalisées dans les threads enfants.
Si l'exo donne juste plusieurs algos et demande lequel fait plus "principal" que les autres, j'aurais du mal à répondre sans l'énoncé complet.

Citation:

---

Envoyé par nouilletonne

Maintenant cela me pose un problème nouveau de savoir si on est dans un cas producteur-consommateur et un cas lecteurs-redacteur.

Comment identifier les deux cas, les deux situations quand un exo est un peu alambiqué utiliserait des termes différents ?

---

Dans le problème des producteurs et des consommateurs, le compteur d'emplacements pleins est incrémenté par les producteurs et décrémenté par les consommateurs.
Dans le problème des lecteurs et des rédacteurs, le compteur de lecteurs n'est modifié que par les lecteurs, pas par les rédacteurs.
Attention, on peut se trouver à la fois dans les deux problèmes ci-dessus : On pourrait avoir des lecteurs et des rédacteurs qui accèdent à un tampon. Parmi ces rédacteurs, on pourrait avoir des producteurs et des consommateurs.

Le mieux pour identifier un algorithme est de le comprendre entièrement.
Pour t'échauffer, dans la page du Wikipédia anglais du problème des lecteurs et des rédacteurs, tu as 3 algorithmes de complexité croissante.

Citation:

---

Envoyé par nouilletonne

Citation:

---

Envoyé par Pyramidev

un mutex qui permet de modifier le tampon.

---

En quoi il modifie le tampon déjà ?

---

Ce n'est pas le mutex qui modifie le tampon. J'aurais dû dire "un mutex qui protège l'accès au tampon".
Si plusieurs threads essaient de modifier le tampon en même temps, il risque de se passer n'importe quoi. Pour éviter que cela arrive, on peut utiliser le mécanisme des mutex.
Un thread qui essaie de bloquer un mutex déjà bloqué s'arrête au moins jusqu'à ce que le mutex soit débloqué.
Du coup, si chaque accès au tampon est précédé par Bloquer(mutex) et suivi par Debloquer(mutex), alors le tampon ne pourra être accessible que par un thread à la fois.
Mais le mutex en lui-même ne connait pas le tampon. Tout ce qu'il fait, c'est faire attendre.

Citation:

---

Envoyé par Pyramidev

Attention, on peut se trouver à la fois dans les deux problèmes ci-dessus : On pourrait avoir des lecteurs et des rédacteurs qui accèdent à un tampon. Parmi ces rédacteurs, on pourrait avoir des producteurs et des consommateurs.

---

Citation:

---

Envoyé par Pyramidev

comment les threads sont lancés pour savoir quelles tâches sont réalisées dans le thread principal et lesquelles sont réalisées dans les threads enfants.

---

Par abus de langage il me semble qu'on considère les threads comme n'importe quel processus. Dans les livres, cours, on fait bien la différence et on nomme en français "thread" par fil au sein d'un même processus.
Peut on dire que dans le cas de plusieurs rédacteurs accédant à un tampon ce serait un processus à plusieurs fil ( "thread") ? Car sinon cela veut dire que l'algo n'est pas bien conçu et qu'on aura une famine ou coalition rédacteurs famine inversé dans le modele lecteurs redacteurs ou un paquet d'erreurs au niveau codage;

Pour autant dans producteur et consommateur, il me parait pourtant normal de considérer le producteur comme l'initiateur du déroulement du code (si consommateur décrémente rien fin de l'histoire).
Pour rédacteur lecteurs, c'est parfois plus difficile mais en général le programme (procédure,fonction,main) qui initialise les sémaphores est le prog principal.

Il est vrai que sur des algos j'ai plus de mal c'est pour ça que depuis 3j j'essaye de coder les exos algo sémaphore vu en cours et pas évident en maniant les fonctions surtout wait lorsque justement je gère plusieurs processus par fork mais je commence à voir le fonctionnement et à transposer un exo au niveau algo en code c.


Sinon justement je ne parlais pas d'exo en particulier mais de bien isoler le démarrage/prog principal d'un algo ou code de n'importe quel exo.
J'irai analyser les algos mais my english is poor and i m a lone some encoder and it s a warm day... sans google traduction sauf pour codeur lol

Citation:

---

Envoyé par nouilletonne

Par abus de langage il me semble qu'on considère les threads comme n'importe quel processus. Dans les livres, cours, on fait bien la différence et on nomme en français "thread" par fil au sein d'un même processus.

---

Les processus lourds ont chacun leur espace mémoire propre.
Un processus lourd peut avoir plusieurs processus légers, aussi appelés fil ou thread, qui partagent l'espace mémoire du processus lourd.
Quand on emploie seulement les termes thread et processus sans dire explicitement processus léger ou processus lourd, alors processus signifie généralement processus lourd.

Citation:

---

Envoyé par nouilletonne

Peut on dire que dans le cas de plusieurs rédacteurs accédant à un tampon ce serait un processus à plusieurs fil ( "thread") ?

---

Oui.

Citation:

---

Envoyé par nouilletonne

Pour autant dans producteur et consommateur, il me parait pourtant normal de considérer le producteur comme l'initiateur du déroulement du code (si consommateur décrémente rien fin de l'histoire).

---

L'initiateur pourrait aussi n'être ni un producteur, ni un consommateur. Il créerait le tampon, un mutex et des sémaphores, puis des threads qui accèderaient au tampon.

ça se verrait cela du pseudo code ou algo je pense ?
que ce soit une procédure ou un fonction qui charge une file sur une zone mémoire genre tableau ou boucle + les mutex et les sem

Citation:

---

Envoyé par Pyramidev

Les processus lourds ont chacun leur espace mémoire propre.
Un processus lourd peut avoir plusieurs processus légers, aussi appelés fil ou thread, qui partagent l'espace mémoire du processus lourd.
Quand on emploie seulement les termes thread et processus sans dire explicitement processus léger ou processus lourd, alors processus signifie généralement processus lourd.

Oui.

---

OK!
Donc en fait là ce serait le même cas que :

Citation:

---

Peut on dire que dans le cas de plusieurs rédacteurs accédant à un tampon ce serait un processus à plusieurs fil ( "thread") ?

---

L'initiateur créerait plusieurs producteurs ou/et consommateurs qui accéderaient à la même mémoire tampon(ou mémoire partagé par les threads du processus "lourd") ?

Citation:

---

Envoyé par Pyramidev

L'initiateur pourrait aussi n'être ni un producteur, ni un consommateur. Il créerait le tampon, un mutex et des sémaphores, puis des threads qui accèderaient au tampon.

---

Merci de ne me répondre (j'exige rien mais c'est juste que mon exam est le 10 Juin) :oops:
Et que j'éprouve des difficultés à transposer en C des exos où il y a des algo sémaphores que je comprend (ou pas d'où l'intéret de le coder pour voir le résultat, ce qui m'entraine à coder les threads, processus, signaux, tubes,etc... et le résultat me fait comprendre aussi l'algo sem non compris ) :calim2: