Le comportement de sched_yield

J'ai quelques questions au sujet de la sched_yield fonction parce que je suis de voir qu'il ne fonctionne pas comme prévu dans mon code. De nombreuses fois, je vois que le même thread s'exécute de nouveau et de nouveau, même en présence d'autres threads, lorsque j'essaie de rendement en appelant sched_yield.

Aussi Si j'ai multicores, sera sched_yield de rendement pour les threads en cours d'exécution sur tous les cœurs, ou un seul noyau. Disons, par exemple, j'ai des Fils 1, 2 et 3 en cours d'exécution sur le core 1 et Fils 4, 5 et 6 sur le noyau 2 et Si sched_yield est appelé par le Thread 2, il sera remplacé par le Thread 1 et 3, ou 1, 3, 4, 5 et 6, tout est possible? Je demande cela parce que, dans .Net Thread.Yield seulement les rendements de threads en cours d'exécution sur le même core/processeur.

Comment voulez-vous qu'il fonctionne? TBH, je ne comprends vraiment pas pourquoi cet appel est utile, que ce soit sur POSIX/***X, Windows ou de tout multitâche préemptif. Si vous le rendement de votre fil, vous n'avez aucune garantie que le système d'exploitation ne sera pas seulement de le charger à nouveau immédiatement, même sur la base même si les autres threads ne sont pas prêt à l'époque. Si l' .NET version a une affinité du processeur, (et oui, je l'ai googlé et il semble qu'il a), qui est encore plus étrange - je suppose qu'il peut améliorer les performances avec des fibres?
il est utile de les appeler quand vous avez plus de processus exécutables/threads que de cœurs et que vous souhaitez donner aux autres threads/processus une chance de faire des progrès (par exemple, un thread a juste donné un autre thread quelque chose à faire et le coût de la première thread d'aller dormir pour attendre à la fin est plus que le coût de l' (le deuxième fil de faire "quelque chose" + le premier thread vérifier que c'est fait).

OriginalL'auteur MetallicPriest | 2011-06-15

  1. 4

    http://www.kernel.org/doc/man-pages/online/pages/man2/sched_yield.2.html

    sched_yield (), le thread appelant à renoncer à la CPU. Le fil est
    déplacé à la fin de la file d'attente pour sa priorité statique et un nouveau thread obtient à
    exécutez.

    Si le thread appelant est le seul fil dans la plus haute priorité à cette liste
    temps, il continuera à fonctionner après un appel à sched_yield().

    La sched_yield est pas un .Net appel et le filetage/modèle de processus est différent. Le planificateur de Windows/.NET n'est pas le même que le planificateur de Linux. Linux ont même plusieurs planificateurs.

    Donc, vos attentes sur sched_yield est faux.

    Si vous voulez contrôler la façon dont les threads, vous pouvez lier chaque thread CPU. Ensuite, des threads de s'exécuter uniquement sur les bindings de l'UC. Si vous avez plusieurs threads, liées à la le même PROCESSEUR, l'utilisation de sched_yield PEUT passer à un autre thread qui est lié à la CPU actuel et est prêt à fonctionner.

    Il peut aussi être une mauvaise idée d'utiliser plusieurs threads par PROCESSEUR si chaque thread veux faire beaucoup de CPU-intensive de travail.

    Si vous voulez obtenir le plein contrôle, la façon dont les threads, vous pouvez utiliser des threads. http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler - SCHED_FIFO et SCHED_RR RT politiques.

    OriginalL'auteur osgx

  2. -4

    Pourquoi voudriez-vous donner le CPU? Eh bien...

    Je suis la correction d'un bogue dans le code client. En gros, ils ont partagé struct qui détient de l'information:

    1. combien de pièces en dépôt - retourner
    2. combien de factures en dépôt - retourner

    Ci-dessus sont dans le processus de A. le reste du code est en processus de B. B envoie des messages à Un Processus de calcul et de rendre l'argent en dépôt (c'est un distributeur automatique). Sans entrer dans l'histoire de pourquoi le code est écrit de cette manière, le code d'origine de la séquence:

    (B)
    envoyer un message RETURN_ESCROWED_BILLS à Un Processus de
    envoyer un message RETURN_ESCROWED PIÈCES à traiter Un
    À zéro, la structure commune

    C'est exécutée en tant que:

    (B):
    envoyer des messages;
    remettre à zéro la structure;

    (plus tard .. Un Processus):
    obtenir les messages;
    tous les champs en commun struct sont 0;
    rien à faire;

    oups ... l'argent n'est toujours bloquée, mais le processus d'Un code a perdu connaissance. Ce qui est vraiment nécessaire (autre qu'un massive restructuration du code) est:

    (B):
    envoyer des messages;
    le rendement de la CPU;

    (Processus):
    déterminer les clés de l'argent et de retour;
    le rendement de la CPU; (pouvez tout simplement aller à la fin de la timeslice, aucune méthode particulière nécessaire)

    (B):
    zéro sur la commune struct;

    Tout moment vous avez la CIB messages et les processus qui les envoyer/recevoir les messages sont étroitement couplé. le meilleur façon est d'avoir un échange en deux étapes. Cependant, il y a des cas (généralement le résultat d'une mauvaise ou inexistante design) où vous devez associer étroitement les processus qui sont vraiment censé être faiblement couplés. Généralement le rendement de l'UC est un hack parce que vous ne disposez pas d'un choix. L'ajout de Processeurs multicœurs est une source de la douleur, en particulier en cas de portage à partir d'une seule base d'un multi-core.

    Cette réponse est fausse. sched_yield() n'est pas fait pour la communication interprocessus, ni en l'appelant à s'assurer qu'un autre thread exécute. Comme décrit par osgx, l'idée est d'aider les OS planifier efficacement.
    oui, sched_yield() n'est pas explicitement pour la communication interprocessus, mais: l'envoi de fil nécessaire pour donner le PROCESSEUR de manière prévisible pour permettre la réception de fil pour avoir une chance d'obtenir le CPU. Aussi, les deux processus sont au même niveau de priorité, et la réception de fil bloque, en attente sur le message. Sinon, il y a une course entre le moment de l'envoi de la tâche perdu de la CPU et de la réception de la tâche a obtenu le CPU. Cette méthode était prévisible (Ubunto 8)

    OriginalL'auteur user2913342