1. #1
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut 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

  2. #2
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    407
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 407
    Points : 1 761
    Points
    1 761

    Par défaut

    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.

  3. #3
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut

    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 ?

  4. #4
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    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 ?

  5. #5
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    407
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 407
    Points : 1 761
    Points
    1 761

    Par défaut

    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 Voir le message
    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 Voir le message
    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.

  6. #6
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    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 Voir le message
    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

  7. #7
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    407
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 407
    Points : 1 761
    Points
    1 761

    Par défaut

    Citation Envoyé par nouilletonne Voir le message
    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 Voir le message
    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 Voir le message
    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.

  8. #8
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut

    ç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

  9. #9
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2015
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2015
    Messages : 187
    Points : 84
    Points
    84

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    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 :
    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 Voir le message
    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)
    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 )

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. SEM 5.2 : courbes de lift dans le noeud "Assesment"
    Par ALLB dans le forum Outils BI
    Réponses: 4
    Dernier message: 20/02/2009, 17h03
  2. Clefs primaire en format aa/sem/numéro
    Par Salsaboy60 dans le forum IHM
    Réponses: 8
    Dernier message: 10/02/2009, 21h10
  3. Graphique dans SAS - v9.1 SAS/GRAPH ou SEM
    Par ALLB dans le forum ODS et reporting
    Réponses: 4
    Dernier message: 04/12/2008, 18h37
  4. Option de compilation gcc : sem.h
    Par Luther13 dans le forum Linux
    Réponses: 8
    Dernier message: 29/12/2004, 12h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo