Pourquoi ne pthreads’ la variable de condition fonctions nécessitent un mutex?

Je suis en train de lire sur pthread.h; la variable de condition fonctions connexes (comme pthread_cond_wait(3)) nécessitent un mutex comme argument. Pourquoi? Aussi loin que je peux dire, je vais créer un mutex juste pour l'utiliser comme argument? Qu'est-ce que ce mutex censé faire?

InformationsquelleAutor ELLIOTTCABLE | 2010-05-04
  1. 180

    C'est juste la manière que les variables de condition sont (ou ont été initialement mises en œuvre.

    Le mutex est utilisé pour protéger de la variable de condition elle-même. C'est pourquoi vous avez besoin verrouillé avant de vous faire attendre.

    L'attente "atomiquement" déverrouille le mutex, permettant à d'autres d'accéder à la variable d'état (pour la signalisation). Puis, lorsque la variable de condition est signalée ou diffusion, un ou plusieurs des fils sur la liste d'attente sera réveillé et le mutex sera magiquement à nouveau verrouillé pour que le thread.

    L'on voit habituellement à la suite de l'opération avec les variables de condition, illustrant la façon dont ils travaillent. L'exemple suivant est un thread de travail qui est donné par l'intermédiaire d'un signal à une variable de condition.

    thread:
    initialise.
    lock mutex.
    while thread not told to stop working:
        wait on condvar using mutex.
        if work is available to be done:
            do the work.
    unlock mutex.
    clean up.
    exit thread.

    Le travail est effectué à l'intérieur de cette boucle, à condition qu'il est disponible lorsque la file d'attente des retours. Lorsque le thread a été signalé à cesser de travailler (généralement par un autre thread réglage de la sortie à l'état de donner des coups de pied de la variable de condition pour réveiller ce fil), la boucle de sortie, le mutex sera débloqué et ce fil sera de sortie.

    Le code ci-dessus est un modèle de consommation que le mutex reste bloqué alors que le travail est fait. Pour un multi-consommation variation, vous pouvez utiliser, par exemple:

    thread:
    initialise.
    lock mutex.
    while thread not told to stop working:
        wait on condvar using mutex.
        if work is available to be done:
            copy work to thread local storage.
            unlock mutex.
            do the work.
            lock mutex.
    unlock mutex.
    clean up.
    exit thread.

    qui permet à d'autres consommateurs de recevoir un travail alors que celui-ci est en train de faire le travail.

    De la variable de condition vous libère du fardeau de l'interrogation de certains état au lieu permettant à un autre thread pour vous avertir lorsque quelque chose doit arriver. Un autre thread peut dire que le thread de travail est disponible comme suit:

    lock mutex.
flag work as available.
signal condition variable.
unlock mutex.

    La grande majorité de ce qui est souvent appelé à tord fallacieux de réveil est généralement toujours parce que plusieurs threads avait été signalé au sein de leur pthread_cond_wait appel (broadcast), on serait de retour avec le mutex, faire le travail, puis re-attendre.

    Puis la deuxième signalé thread pourrait sortir quand il n'y avait pas de travail à faire. Donc, vous avez dû avoir une variable supplémentaire indiquant que le travail doit être fait (c'était intrinsèquement mutex-protégé avec le condvar/mutex paire ici - d'autres threads nécessaire pour verrouiller le mutex avant de le changer, cependant).

    Il était techniquement possible pour un fil de retour d'un état d'attente sans être frappé par un autre processus (c'est une vraie fausse de réveil), mais, dans tous mes nombreuses années de travail sur les pthreads, à la fois dans le développement/service de la code et en tant qu'utilisateur d'eux, je n'ai jamais reçu un de ces. Peut-être que c'était juste parce que HP a fait une bonne mise en œuvre 🙂

    Dans tous les cas, le même code, qui traite les erronée cas également traitées de véritables parasites de réveils ainsi depuis les travaux disponibles du drapeau ne seraient pas pour ceux.

    • +1 pour le modèle de la façon d'utiliser les mutex et les condvars; qu'il en est toujours fait. (Eh bien, à part quand c'est fait à tort...)
    • "faire quelque chose" ne devrait pas être à l'intérieur de la boucle while. Vous voulez de votre temps boucle de simplement vérifier l'état, faute de quoi vous risquez également de "faire quelque chose" si vous obtenez un faux réveil.
    • Eh bien, oui, vous devez vérifier la condition d'erreur, je pense que irait sans dire. Mais, à supposer qu'il y en avait pas, vous avez le mutex et il serait à l'abri de "faire quelque chose". Je vais préciser.
    • non, erreur de manipulation est en second lieu à ce. Avec les pthreads, vous pouvez être réveillé, sans raison apparente(un faux réveil) , et avec toute erreur. Vous devez donc vérifier de nouveau "certaines conditions" après vous êtes réveillé.
    • Je ne suis pas sûr de comprendre. J'ai eu la même réaction que nos; pourquoi est - do something à l'intérieur de la while boucle?
    • Parce que c'est quand vous avez été signalée avec la variable de condition. la nsa est juste que votre fils peut se réveiller avec aucun travail à faire (il n'a jamais été falsifiés par la voie, ce qui allait se passer, c'est qu'il a été possible pour deux threads à être réveillés dans leur cond_wait puis on va revenir avec le mutex et de faire le travail, puis, quand il rewaited sur la condition, la deuxième serait de retour et pas de travail pour elle). Je considère qu'une condition d'erreur donc mes modifications. Évidemment, quelques précisions sont nécessaires.
    • Je suis peut-être pas assez clair. La boucle est pas attendre de travail pour être prêt, de sorte que vous pouvez le faire. La boucle est le principal "infini" travail de la boucle. Si vous revenez de cond_wait et le travail drapeau est réglé, vous faire le travail puis la boucle autour de nouveau. "alors que certains la condition" ne seront faux lorsque vous souhaitez que le thread cesser de travailler, à quel point elle va libérer le mutex et les plus susceptibles de sortie.
    • Ahhhhhhhhhhh je vois. Merci pour la clarification, c'était un peu ambigu. +1 maintenant, si vous devez le modifier et de le rendre plus clair.
    • Un nouveau problème, depuis votre dernière modification: Euh, vous pouvez verrouiller/déverrouiller le mutex dans la consommation hors le travail de la boucle. Cela signifie que, sauf quand c'est bloqué en raison de la condvar-attends, le mutex serait toujours bloqué... alors comment pourriez-vous avoir plusieurs consommateurs? Ne devrait pas, alors, le verrouillage/déverrouillage de l'intérieur de la boucle?
    • Non, le cond_wait déverrouille le mutex automatiquement et re-verrouille avant de retourner. Tandis que le thread est dans le cond_wait appel, il n'a pas le mutex est verrouillé.
    • Oui, mais je dis que ce code permettrait d'éviter deux ‘threads’ d'être active à la fois, en travaillant sur les différents éléments de la posé la file d'attente de travail à être fait. Droit?
    • Oui, il serait (désolé, j'ai mal compris votre dernier commentaire), l'exemple est clair multi-producteurs, un seul modèle de consommation. Il est assez facile de se déplacer à un multi-consommateur option si vous copiez les éléments de travail et de libérer le mutex avant de faire le travail, affirmant à nouveau par la suite. C'est juste un mineur mod.
    • Un autre pointilleux peu au sujet de votre dernière modifiés psuedocode: si je ne me trompe, il semble que seul un thread peut jamais être en attente sur la condvar à un moment donné (les autres pourront être verrouillées pour empêcher le mutex, avant de commencer à attendre sur le condvar); n'a pas ce genre de défaite le point? c'est à dire avoir plusieurs threads en attente sur le condvar, puis pthread_cond_signal() ing contre elle, à cause de l'un de ceux qui de se réveiller et prendre un morceau de travail.
    • Je suis curieux de savoir ce que vous pensez de ma mise en œuvre jusqu'à présent. Puisque vous ne pouvez pas exactement de coller le code dans les commentaires: gist.github.com/390498
    • alors qu'un thread est dans le condvarwait, il n'a pas le mutex verrouillé (voir le troisième paragraphe de ma réponse). Donc votre affirmation selon laquelle les autres threads sera en attente sur le mutex n'est pas correct. Il ne serait pas question même si c'était le cas étant donné que, dans le multi-modèle de consommation, le thread déverrouille le mutex, dès qu'il a commencé le travail (après la copie, le stockage local de threads), permettant à un autre thread pour entrer condvarwait. Mais ce n'est pas vraiment le cas (comme expliqué au début de ce commentaire) donc il n'a pas d'importance.
    • Re la revue de code, je vous suggère de l'essayer sous la charge. Si vous trouvez un problème, je serais heureux de le regarder tout les détails ensuite. Je suis heureux de vous aider avec des questions spécifiques et des problèmes, mais mon travail de jour, malheureusement, ne me permet pas de grand effort des revues de code. De toute façon, je la haine revues de code, presque autant que je déteste la documentation 🙂
    • Pas de problème, l'homme. Vous avez déjà été un énorme, énorme aide. J'essayais juste de comprendre si ma demande de le mutex/condvar modèle a été, vous le savez, "correct" (pour une définition de ‘corriger.’)
    • Je suis curieux de savoir comment vous savez que vous n'avez jamais reçu un faux réveil puisque, comme vous le dites, le même code, qui traite les erronée cas également traitées de véritables parasites de réveils ainsi.
    • Peut-être parce que, au début du développement, nous avons supposé que tous les réveils étaient authentiques et codé pour que. Même si toujours lieu, nous avons ajouté la fausse vérifier plus tard. Que serait ma meilleure supposition, de vous étirer ma mémoire un peu mais 🙂
    • Juste parce que vous avez demandé, les défauts: 1) comme il a déjà corrigé maintenant, le mutex est encore à protéger de la variable de condition, il n'y a pas d'autre moyen de le protéger. 2) il ne doit pas être une façon différente de gérer un seul ou de plusieurs consommateurs, comme indiqué dans la réponse de la nsa, où le traitement est effectué à l'extérieur de la serrure.
    • 3) Il n'est pas forcément une meilleure solution si il ne sont pas les réveils intempestifs, il y a peut être un moyen plus efficace de gérer les variables de condition, qui vient de se produire pour générer un faux réveil, votre code ne devraient tout simplement pas de soins. 4) en parlant de l'efficacité, vous pouvez le déverrouiller avant de signaler que la variable de condition, surtout si le récepteur a une plus grande priorité.
    • Je ne vois pas vraiment l'un de ceux que des défauts. (1) est corrigée comme vous le dites, (2) est juste deux façons de faire les choses, la multi-consommation gère les deux cas, bien, mais vous pouvez utiliser plus simple de code pour un seul consommateur (pas besoin pour le stockage local de copie), (3) n'est pas pertinente car il y a est fausse réveils possible et (4) c'est discutable puisque celui-ci doit faire deux ops de toute façon avant de garçon peut être prévue. Donc, je pense que je vais laisser la réponse en tant que-est. Si vous pensez que le rend véritablement non-utile, c'est ce que le système de vote est pour. Mais je n'ai pas, évidemment. Merci pour la clarification, je ne l'apprécier.
    • mutex est encore à protéger de la variable de condition, il n'y a pas d'autre moyen de protéger" : le mutex est pas pour protéger la variable de condition; c'est pour protéger le prédicat de données, mais je pense que vous savez qu'à partir de la lecture de votre commentaire qui a suivi cette déclaration. Vous pouvez signaler une variable de condition légalement, et entièrement pris en charge par des implémentations, post-déverrouillage du mutex, enveloppant le prédicat, et en fait, vous ferez soulager de querelles de le faire dans certains cas.
    • oui, le mutex n'est PAS de protéger la variable de condition.
    • pouvez-vous à la documentation qui pourrait l'indiquer. J'ai couru dans beaucoup de revendications contradictoires et cette réponse est référencé dans d'autres endroits pour soutenir l'idée que le mutex protège la variable de condition elle-même.
    • avez-vous une source pour l'allégation "Le mutex est utilisé pour protéger l'état de la variable elle-même." J'ai trouvé indirecte d'éléments de preuve contradictoires ici: linux.die.net/man/3/pthread_cond_wait, sous la rubrique Features of Mutexes and Condition Variables
    • juste ma connaissance de la mise en œuvre réelle qui a été utilisé dans hp-ux beaucoup lunes auparavant. En gros, c'est pourquoi la condvar et mutex étaient liés étroitement. Si c'est le cas avec les implémentations modernes, je ne pouvais pas le dire.

    InformationsquelleAutor paxdiablo
  2. 56

    Une variable de condition est assez limité si seulement vous pouviez être le signal d'un état, en général, vous devez gérer certaines données qui sont liées à la condition qui a été signalée. Signalisation/réveil, doivent être faites de manière atomique en ce qui concerne réaliser que sans l'introduction de conditions de course, ou être trop complexe

    pthreads peut aussi vous donner , plutôt pour des raisons techniques, un fallacieux de réveil . Cela signifie que vous avez besoin de vérifier un prédicat, de sorte que vous pouvez être sûr que l'état de fait a été signalé - et la distinction que d'une fausse réveil. La vérification de cette condition en ce qui concerne attend-il besoin d'être gardés donc une variable de condition a besoin d'un moyen de atomiquement attendre/réveil lors du verrouillage/déverrouillage d'un mutex préserver cette condition.

    Prenons un exemple simple où vous êtes informé que les données sont produites. Peut-être un autre thread fait certaines des données que vous souhaitez et de définir un pointeur vers les données.

    Imaginer un producteur de fil en donnant quelques données sur un autre thread consommateur par le biais d'un 'some_data'
    pointeur.

    while(1) {
    pthread_cond_wait(&cond); //imagine cond_wait did not have a mutex
    char *data = some_data;
    some_data = NULL;
    handle(data);
}

    vous feriez naturellement beaucoup de course a condition, que si l'autre thread n'a some_data = new_data juste après que vous avez obtenu de se réveiller, mais avant que vous ne data = some_data

    Vous ne peut pas vraiment créer votre propre mutex pour garder ce cas non plus .e.g

    while(1) {

    pthread_cond_wait(&cond); //imagine cond_wait did not have a mutex
    pthread_mutex_lock(&mutex);
    char *data = some_data;
    some_data = NULL;
    pthread_mutex_unlock(&mutex);
    handle(data);
}

    Ne fonctionnera pas, il y a encore une chance d'une condition de concurrence entre le réveil et le saisissant le mutex. Placer le mutex avant la pthread_cond_wait ne vous aide pas, comme vous maintenant
    maintenez le mutex en attendant - à-dire le producteur ne sera jamais en mesure de saisir le mutex.
    (remarque, dans ce cas, vous pourriez créer une seconde variable d'état de signal pour le producteur que vous avez terminé avec some_data - bien que cela va devenir complexe, surtout si vous voulez que de nombreux producteurs/consommateurs.)

    Donc vous avez besoin d'un moyen de atomiquement de presse/saisir le mutex en attente/le réveil de la condition. C'est ce que pthread les variables de condition, et voici ce que vous devriez faire:

    while(1) {
    pthread_mutex_lock(&mutex);
    while(some_data == NULL) { //predicate to acccount for spurious wakeups,would also 
                               //make it robust if there were several consumers
       pthread_cond_wait(&cond,&mutex); //atomically lock/unlock mutex
    }

    char *data = some_data;
    some_data = NULL;
    pthread_mutex_unlock(&mutex);
    handle(data);
}

    (le producteur serait naturellement besoin de prendre les mêmes précautions, toujours de gardiennage 'some_data" avec le même mutex, et de faire en sorte qu'il n'écrase pas some_data si some_data est actuellement != NULL)

    • Ne pas le while (some_data != NULL) être un do-while boucle de sorte qu'il attend de la variable de condition, au moins une fois?
    • Pas de. Ce que vous êtes réellement à l'attente, c'est pour "some_data' être non-nulle. Si elle est non nulle, la "première fois", très bien, vous êtes en attente du mutex et peuvent utiliser en toute sécurité les données. Si vous aviez une boucle do-while vous manquez la notification, si quelqu'un a signalé la variable de condition avant de vous attendu sur elle (c'est rien comme les événements trouvés sur win32 qui restent signalé jusqu'à ce que quelqu'un les attend)
    • Je viens de tombé sur cette question, et franchement, c'est bizarre de constater que cette réponse, qui est juste correct a beaucoup moins de points que paxdiablo de la réponse, qui a défini les défauts (atomicité est encore nécessaire, que le mutex n'est nécessaire pour le traitement de la condition, pas de manipulation ou de la notification). Je suppose que c'est juste la façon dont stackoverflow fonctionne...
    • si vous souhaitez en détail les défauts, comme des commentaires de ma réponse, donc je les vois en temps opportun, plutôt que des mois plus tard :-), je serai heureux de les corriger. Vos brèves phrases n'ont pas vraiment de me donner suffisamment de détails pour travailler sur ce que vous essayez de dire.
    • ne devrait pas while(some_data != NULL) être while(some_data == NULL)?
    • Quelle est la cause de la fausse réveils? Si c'était garanti, ce thread ne réveiller par le signal, le mutex être encore nécessaire?
    • la raison de la fausse réveils, c'est que pour le noyau de la mise en œuvre est une condition de course. Alors qu'il serait possible d'éliminer la condition de la course, il aurait coûts de l'exécution de le faire. Par conséquent, la norme permet de fausse les conditions de concurrence afin de permettre la meilleure performance possible à partir du noyau.

    InformationsquelleAutor nos
  3. 29

    POSIX variables de condition sont apatrides. Donc, il est de votre responsabilité de maintenir l'état. Étant donné que l'état sera accessible par les deux threads qui attendent que le nombre de threads et que dire des autres threads arrêter d'attendre, il doit être protégée par un mutex. Si vous pensez que vous pouvez utiliser des variables de condition, sans un mutex, alors vous n'avez pas compris que les variables de condition sont apatrides.

    Les variables de Condition sont construits autour d'un état. Les Threads en attente sur une variable de condition sont en attente d'une condition. Les Threads que le signal de variables de condition de modifier cette condition. Par exemple, un thread peut être en attente pour certains de données pour arriver. Un autre thread peut remarquer que les données sont arrivées. "Les données sont arrivées" est la condition.

    Ici est l'utilisation classique d'une variable de condition, simplifié:

    while(1)
{
    pthread_mutex_lock(&work_mutex);

    while (work_queue_empty())       //wait for work
       pthread_cond_wait(&work_cv, &work_mutex);

    work = get_work_from_queue();    //get work

    pthread_mutex_unlock(&work_mutex);

    do_work(work);                   //do that work
}

    Voir comment le thread est en attente pour le travail. L'œuvre est protégée par un mutex. L'attente libère le mutex, de sorte qu'un autre thread puisse donner à ce fil un peu de travail. Voici comment il serait signalé:

    void AssignWork(WorkItem work)
{
    pthread_mutex_lock(&work_mutex);

    add_work_to_queue(work);           //put work item on queue

    pthread_cond_signal(&work_cv);     //wake worker thread

    pthread_mutex_unlock(&work_mutex);
}

    Avis que vous besoin le mutex pour protéger la file d'attente de travail. Notez que la variable d'état lui-même n'a aucune idée si il y a du travail ou pas. C'est, une variable de condition doit être associés à une condition, que la condition doit être maintenu par votre code, et depuis il est partagé entre les threads, elle doit être protégée par un mutex.

    • Ou, pour le dire de façon plus concise, l'ensemble du point de variables de condition est de fournir atomique "déverrouiller et d'attendre de l'opération". Sans un mutex, il n'y aurait rien à débloquer.
    • Pourriez-vous nous expliquer le sens de apatrides?
    • Ils n'ont pas d'état. Ils ne sont pas "verrouillé" ou "signalé" ou "unsignaled". Donc, il est de votre responsabilité de garder une trace de ce que l'état est associé à la variable de condition. Par exemple, si la variable de condition permet à un thread de savoir quand une file d'attente devient non-vide, il doit être le cas qu'un thread peut faire la file d'attente non-vide et un autre thread a besoin de savoir quand la file d'attente devient non-vide. C'est un état partagé, et vous devez le protéger avec un mutex. Vous pouvez utiliser la variable de condition, en association avec qui partagé de l'état protégée par un mutex, comme le mécanisme de réveil.
    InformationsquelleAutor David Schwartz
  4. 13

    Pas tous de la variable de condition fonctions nécessitent un mutex: seule l'attente des opérations à faire. Le signal et de l'émission des opérations ne nécessitent pas un mutex. Une variable de condition n'est pas associée de façon permanente avec un mutex spécifique; l'externe mutex ne protège pas de la variable de condition. Si une condition variable d'état interne, comme une file d'attente des threads en attente, ce doit être protégé par un verrou interne à l'intérieur de la variable de condition.

    L'attente des opérations de réunir une variable de condition et un mutex, parce que:

    • un thread a verrouillé le mutex, évalué certains d'expression par les variables partagées et trouvé que c'était faux, tel qu'il doit attendre.
    • le thread doit atomiquement déplacer de posséder le mutex, pour les en attente sur la condition.

    Pour cette raison, l'opération d'attente prend comme arguments à la fois le mutex et de l'état: de sorte qu'il peut gérer le transfert atomique d'un fil de posséder le mutex de l'attente, de sorte que le thread ne pas tomber victime de la perdu de réveil condition de course.

    La perte d'un réveil à condition de concurrence se produit si un thread donne un mutex, puis attend une apatrides de la synchronisation de l'objet, mais d'une manière qui n'est pas atomique: il existe une fenêtre de temps où le thread n'a plus la serrure, et n'a pas encore commencé en attente sur l'objet. Au cours de cette fenêtre, un autre thread peut venir dans, faire l'attendu condition vrai, le signal de la apatrides de synchronisation et puis disparaissent. Les apatrides objet n'oubliez pas qu'il a été signalé (il est apatride). Alors que le thread d'origine va dormir sur le apatrides de la synchronisation de l'objet, et ne pas se réveiller, même si elle a déjà devenir réalité: perdu réveil.

    De la variable de condition attendre fonctions d'éviter les perdus de réveil par faire en sorte que le thread appelant est enregistré de manière fiable attraper le réveil avant qu'il abandonne le mutex. Ce serait impossible si l'état variable en fonction d'attente n'a pas pris le mutex comme un argument.

    • Pourriez-vous fournir une référence qui diffusent des opérations ne nécessitent pas d'acquérir le mutex? Sur MSVC la diffusion est ignoré.
    • MSVC a pthreads maintenant?
    • POSIX pthread_cond_broadcast et pthread_cond_signal opérations (que ce DONC, la question est sur) ne prennent même pas le mutex comme argument; seulement la condition. POSIX spec est ici. Le mutex est seulement mentionnée en référence à ce qui se passe dans les threads en attente quand ils se réveillent.
    • Pourriez-vous nous expliquer le sens de apatrides?
    • Un apatride objet de synchronisation ne se souvient pas de tout etat lié à la signalisation. Au signal, si quelque chose est en attente sur elle maintenant, elle est réveillée, sinon, le réveil est oublié. Les variables de Condition sont apatrides comme ça. L'état nécessaire pour rendre la synchronisation fiable est maintenue par l'application et protégée par le mutex qui est utilisé en conjonction avec les variables de condition, selon correctement écrits de logique.
    InformationsquelleAutor Kaz
  5. 6

    Je ne trouve pas les autres réponses pour être aussi concis et facile à lire que cette page. Normalement, l'attente, le code ressemble à ceci:

    mutex.lock()
while(!check())
    condition.wait()
mutex.unlock()

    Il y a trois raisons pour envelopper le wait() dans un mutex:

    1. sans un mutex un autre thread pourrait signal() avant la wait() et nous rater ce réveil.
    2. normalement check() dépend de la modification d'un autre thread, si vous avez besoin d'exclusion mutuelle sur elle de toute façon.
    3. pour s'assurer que le thread de priorité plus élevé procède en premier (la file d'attente du mutex permet au planificateur de décider qui va à côté).

    Le troisième point n'est pas toujours une source de préoccupation - le contexte historique est accessible à partir de l'article de cette conversation.

    Fausse wake-up est souvent évoqué à l'égard de ce mécanisme (c'est à dire le thread en attente est réveillé sans signal() être appelé). Toutefois, ces événements sont gérés par la boucle check().

    InformationsquelleAutor Sam Brightman
  6. 4

    Les variables de Condition sont associées à un mutex parce que c'est la seule façon d'éviter la course qu'il est conçu pour éviter.

    //incorrect usage:
//thread 1:
while (notDone) {
    pthread_mutex_lock(&mutex);
    bool ready = protectedReadyToRunVariable
    pthread_mutex_unlock(&mutex);
    if (ready) {
        doWork();
    } else {
        pthread_cond_wait(&cond1); //invalid syntax: this SHOULD have a mutex
    }
}

//signalling thread
//thread 2:
prepareToRunThread1();
pthread_mutex_lock(&mutex);
   protectedReadyToRuNVariable = true;
pthread_mutex_unlock(&mutex);
pthread_cond_signal(&cond1);

Now, lets look at a particularly nasty interleaving of these operations

pthread_mutex_lock(&mutex);
bool ready = protectedReadyToRunVariable;
pthread_mutex_unlock(&mutex);
                                 pthread_mutex_lock(&mutex);
                                 protectedReadyToRuNVariable = true;
                                 pthread_mutex_unlock(&mutex);
                                 pthread_cond_signal(&cond1);
if (ready) {
pthread_cond_wait(&cond1); //uh o!

    À ce point, il n'y a pas de fil qui va du signal de la variable de condition, de sorte thread1 attendra toujours, même si le protectedReadyToRunVariable dit qu'il est prêt à aller!

    La seule façon de contourner cela est pour les variables de condition de atomiquement libérer le mutex, tout en commençant à attendre sur la variable de condition. C'est pourquoi le cond_wait fonction nécessite un mutex

    //correct usage:
//thread 1:
while (notDone) {
    pthread_mutex_lock(&mutex);
    bool ready = protectedReadyToRunVariable
    if (ready) {
        pthread_mutex_unlock(&mutex);
        doWork();
    } else {
        pthread_cond_wait(&mutex, &cond1);
    }
}

//signalling thread
//thread 2:
prepareToRunThread1();
pthread_mutex_lock(&mutex);
   protectedReadyToRuNVariable = true;
   pthread_cond_signal(&mutex, &cond1);
pthread_mutex_unlock(&mutex);
    InformationsquelleAutor Cort Ammon
  7. 3

    Le mutex est censé être verrouillé lorsque vous appelez pthread_cond_wait; quand vous l'appelez, il atomiquement les deux déverrouille le mutex, puis se bloque sur la condition. Une fois que le problème est signalé, il atomiquement ce qu'il se verrouille à nouveau et retourne.

    Cela permet la mise en œuvre de la prévisibilité de la planification si vous le souhaitez, en ce que le fil qui ferait de la signalisation peut attendre jusqu'à ce que le mutex est libéré pour effectuer son traitement et signaler l'état.

    • Alors... est-il une raison pour moi de pas, il suffit de laisser le mutex toujours débloqué, puis verrouiller avant de le d'attente, et puis déverrouiller la droite après une attente de finitions?
    • Le mutex résout également un certain potentiel courses entre l'attente et la signalisation des threads. aussi longtemps que le mutex est toujours verrouillé lorsque l'évolution de la condition et de la signalisation , vous ne serez jamais vous retrouver manquant le signal et dormir pour toujours
    • Alors... je devrais premier attendez-sur-mutex sur le conditionvar du mutex, avant de s'en attente sur le conditionvar? Je ne suis pas sûr de comprendre à tous.
    • Sans tenir le mutex, comment pourriez-vous savoir si vous devriez ou ne devriez pas attendre? Si ce que vous êtes en attente pour tout est-il arrivé?
    InformationsquelleAutor Amber
  8. 1

    J'ai fait un exercice en classe, si vous voulez un exemple réel de la variable de condition :

    #include "stdio.h"
#include "stdlib.h"
#include "pthread.h"
#include "unistd.h"

int compteur = 0;
pthread_cond_t varCond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mutex_compteur;

void attenteSeuil(arg)
{
    pthread_mutex_lock(&mutex_compteur);
        while(compteur < 10)
        {
            printf("Compteur : %d<10 so i am waiting...\n", compteur);
            pthread_cond_wait(&varCond, &mutex_compteur);
        }
        printf("I waited nicely and now the compteur = %d\n", compteur);
    pthread_mutex_unlock(&mutex_compteur);
    pthread_exit(NULL);
}

void incrementCompteur(arg)
{
    while(1)
    {
        pthread_mutex_lock(&mutex_compteur);

            if(compteur == 10)
            {
                printf("Compteur = 10\n");
                pthread_cond_signal(&varCond);
                pthread_mutex_unlock(&mutex_compteur);
                pthread_exit(NULL);
            }
            else
            {
                printf("Compteur ++\n");
                compteur++;
            }

        pthread_mutex_unlock(&mutex_compteur);
    }
}

int main(int argc, char const *argv[])
{
    int i;
    pthread_t threads[2];

    pthread_mutex_init(&mutex_compteur, NULL);

    pthread_create(&threads[0], NULL, incrementCompteur, NULL);
    pthread_create(&threads[1], NULL, attenteSeuil, NULL);

    pthread_exit(NULL);
}
    InformationsquelleAutor Central Thinking Unit
  9. 1

    Il semble être une conception spécifique de décision plutôt que conceptuelle besoin.

    Par les pthreads docs la raison que le mutex n'a pas été séparés est qu'il y a une amélioration significative de la performance en combinant entre eux et ils attendent que la raison de conditions de course si vous n'utilisez pas un mutex, c'est presque toujours va être fait de toute façon.

    https://linux.die.net/man/3/pthread_cond_wait

    Caractéristiques de Mutex et les Variables de Condition

    Il avait été suggéré que le mutex d'acquisition et de libération
    découplé de l'état d'attente. Cette idée a été rejetée, car elle est la
    combiné la nature de l'opération qui, en fait, facilite en temps réel
    les implémentations. Ces implémentations peuvent atomiquement déplacer un
    thread de priorité élevée entre la variable de condition et le mutex dans un
    de manière transparente pour l'appelant. Cela peut empêcher les autres
    les changements de contexte et de fournir plus déterministe de l'acquisition d'un mutex
    lorsque le thread en attente est signalé. Ainsi, l'équité et la priorité
    les questions peuvent être traitées directement par la planification de la discipline.
    En outre, l'état actuel attendre opération correspond existant
    de pratique.

    InformationsquelleAutor Catskul
  10. 0

    Il y a des tonnes d'exégèses à ce sujet, mais je veux incarner avec un exemple qui suit. 

    1 void thr_child() {
2    done = 1;
3    pthread_cond_signal(&c);
4 }

5 void thr_parent() {
6    if (done == 0)
7        pthread_cond_wait(&c);
8 }

    Quel est le problème avec l'extrait de code? Juste réfléchir un peu avant d'aller de l'avant.

    La question est vraiment subtile. Si le parent appelle
    thr_parent() et puis, les vétérinaires, la valeur de done, il va voir qu'il est 0 et
    donc essayer d'aller dormir. Mais juste avant d'appeler attendre d'aller dormir, le parent
    est interrompu entre les lignes de 6-7, et l'enfant s'exécute. L'enfant des changements de la variable d'état
    done à 1 et des signaux, mais pas de thread est en attente et donc pas de thread
    réveillé. Lorsque le parent se présente à nouveau, elle dort toujours, qui est vraiment flagrant.

    Que si elles sont réalisées alors que les verrous acquis individuellement?

    InformationsquelleAutor snr