Discussion :

[leandro95]

Bonjour je suis complètement perdu sur mon exercice d'entrainement aux sémaphore,quelqu'un pourrait m'aider,il me guider pas à pas svp:

on étudie le problème producteur-consommateur. Supposons
que l’on souhaite pouvoir échanger des données entre 10 threads producteurs
et 10 threads consommateurs. Cela se fait par l’utilisation d’un tampon partage.
Chacun de ces producteurs souhaite écrire son nom et son produit dans le tampon
afin qu’il soit lu par le consommateur.

1. Dans un premier temps, on implémente une solution au problème sans utilisation
de sémaphore. Dans cette solution, on souhaite que chaque producteur
affiche son nom et son produit pour chaque écriture et que le consommateur
affiche ce qu’il a lu pour chaque lecture.
(a) Écrire une fonction main() qui lance les threads producteurs et les
threads consommateurs, ainsi que les fonctions définissant le comportement
des threads.
(b) Observer l’affichage du programme pour voir s’il y a des incohérences
de données.
2. Implémenter une solution au problème avec utilisation de sémaphore. Comparer
les deux solutions.

[Sve@r]

Bonjour

Perso je n'utilise pas les thread donc je ne sais pas m'en servir mais c'est annexe.

Un sémaphore est un outil destiné à protéger une (ou plusiers) ressource d'accès concurrents (et destructeurs) éventuels. Par exemple dans ta zone tampon, si T1 (le thread n° 1) écrit un truc et que T2 écrit autre chose, l'info de T1 est perdue. Le sémaphore (qui est géré par l'OS) permet d'empêcher cela.
Il faut travailler de la façon suivante

1. tu initialises ton sémaphore à "n" (n" étant le nombre de ressources à protéger).
2. chaque thread qui veut accéder aux ressources effectue une décrémentation de "n". Admettons à ce moment là qu'il y en ait deux. La magie du sémaphore entre alors en jeu car étant donné qu'il ne peut pas être négatif, un seul des threads pourra effectuer cette décrémentation ; tandis que l'autre restera bloqué, en attente que l'opération se fasse.
3. le thread qui a "pu passer" peut alors tranquillement travailler sur l'ensemble des ressources en question
4. ce même thread finit son travail. Il effectue alors une incrémentation de "n", le sémaphore remonte à sa valeur "n" initiale
5. l'autre thread qui était en attente peut alors effectuer sa décrémentation. Le sémaphore repasse à 0 bloquant alors tout autre thread éventuel pendant que le thread en question fait lui ce qu'il avait à faire.
6. l'autre thread termine et "referme" alors le sémaphore en lui incrémentant sa valeur. D'autres threads qui ont besoin des ressources peuvent alors si besoin le "réouvrir" par la décrémentation. Le même mécanisme se reproduira...

[leandro95]

Je ne comprend pas l’initialiser à "n" c'est à dire ? le sémaphore est à 10 ?après c'est une boucle de 10 à 0 mais comment décrémenter une sémaphore n fois j'utilise une boucle sur sem_wait() n fois

[Sve@r]

[*] tu initialises ton sémaphore à "n" (n" étant le nombre de ressources à protéger).

Je ne comprend pas l’initialiser à "n" c'est à dire ? le sémaphore est à 10 ?après c'est une boucle de 10 à 0 mais comment décrémenter une sémaphore n fois j'utilise une boucle sur sem_wait() n fois

Pourquoi "10" ? Aurais-tu 10 ressources à protéger ??? C'est quand-même simple: il y a une place de parking, et 500 voitures qui veulent y entrer. Est-ce que tu mettras une barrière ou bien 500 barrières ???

Et "décrémenter de n". Tu ne sais donc pas faire une simple soustraction (ici ce sera plutôt un sem_op) que tu veuilles faire une boucle ???

[dinobogan]

Ici ton sémaphore est utilisé comme un mutex. La valeur maximal du sémaphore sera 1.

PS : D'ailleurs, c'est étonnant d'utiliser un sémaphore et non un mutex dans un programme multi-thread. Sauf si tu confonds thread et processus ?

[Sve@r]

PS : D'ailleurs, c'est étonnant d'utiliser un sémaphore et non un mutex dans un programme multi-thread.

Hum.. dans la mesure ou un mutex n'est qu'un sémaphore particulier, autant rester général non ?

Sauf si tu confonds thread et processus ?

Ben moi je les confonds un petit peu. Me semble qu'un thread c'est le nom que windows donne à ses procesus. Et que ça y ressemble beaucoup sauf que les processus Unix sont bien séparés en tout alors que les thread windows, eux, partagent tout. C'est un peu comme ça que je les vois. Et donc qu'utiliser un sémaphore pour réguler plusieurs threads n'est pas incompatible...

[dinobogan]

Hum.. dans la mesure ou un mutex n'est qu'un sémaphore particulier, autant rester général non ?

Je parlais de sémaphore au sens IPC (externe au processus, gérer par l'OS) et du mutex au sens pthread_mutex_t (interne au processus, invisible de l'extérieur).

Ben moi je les confonds un petit peu. Me semble qu'un thread c'est le nom que windows donne à ses procesus. Et que ça y ressemble beaucoup sauf que les processus Unix sont bien séparés en tout alors que les thread windows, eux, partagent tout. C'est un peu comme ça que je les vois. Et donc qu'utiliser un sémaphore pour réguler plusieurs threads n'est pas incompatible...

Les threads Unix partagent tout également. Utilisé un sémaphore n'est pas incompatible, c'est vrai. Mais c'est dommage d'utiliser une ressource IPC pour un usage exclusivement interne à un processus.
Mais c'est très certainement dans le cadre d'un exercice, donc tu peux oublier ma remarque