Discussion :

[heazen]

Bonjour,

Il existe une fonction faisant à priori la même chose que les sémaphore, cette fonction est sched_yield, elle prend nettement moins de temps que les sémaphores, mais je ne comprends pas pourquoi?

Est-ce que c'est dû au fait que sched_yield est un appel système donc moins couteux que sémaphores posix (appel bibliothéque) ou bien au fait que sched_yield ne soit pas bloquante contrairement aux instructions liées aux sémaphores?

Lorsqu'un processus est bloqué par un sémaphore, il est retiré de la liste de processus prêts et est placé dans la file des processus bloqués. Il n'aura donc plus le processeur jusqu'à ce que le sémaphore soit libéré.
De ce que je sais, sched_yield ne fait juste qu'enlever le processeur au processus courant sans le bloquer (le processus est replacé à la fin de la file de processus prêt associée à sa priorité). Une sorte de préemption manuelle en somme. Est-ce la raison de cette différence de temps ?

[mith06]

Salut,
Je n'ai jamais utilisé cette méthode, mais tu as bien décrit son fonctionnement et si tu te relis je pense que tu vas te répondre tout seul:

semaphore :

processus prêts et est placé dans la file des processus bloqués

sched_yield:

le processus est replacé à la fin de la file de processus prêt associée à sa priorité

Ces fonction ne font donc pas le même chose, d'où la différence de temps.

Si il existe un équivalent pour les thread je suis intéressé!!

@+

[heazen]

Merci pour t'as réponse. Mais j'aimerais savoir en quoi être en placé dans la file des bloqué plutôt qu'en fin de file prend plus de temps ? Est-ce vraiment la raison ?

[mith06]

Salut,

Je ne suis pas suffisamment calé en OS pour répondre avec assurance, mais je suppose que cela vient du au fait que lorsque que le processus est arrêté dans la file , le processeur est interrompu. Je m'explique:

Lorsque que tous les processus attendent un sémaphore, le processeur doit se mettre dans un état où il ne consomme plus d'énergie (instruction du type WaitForInterrupt), puisqu'il n'y a plus rien a exécuter.

Alors que lorsque le processus est replacé en début de file l’exécution des processus continue sans interruption, ce qui doit prendre moins de temps.

Encore une foi je n'en suis pas certain.

[matafan]

Il n'y a absolument aucun rapport entre sched_yield et les sémaphores. Je ne vois pas ce qui te fais penser que ça fait la même chose. Si tu nous expliques ton raisonnement, on pourras t'expliquer ce que tu n'as pas compris.

[heazen]

Aucun rapport ? tu prend 2 processus, les sémaphore te permet de donner la main à l'un, puis à l'autre, et sched_yield aussi ... imaginons dans le cas d'un fork .. ou de threads ...

[matafan]

Un sémaphore sert à bloquer un processus en attente d'une ressource, ce que sched_yield() ne permet absolument pas de faire.

[Obsidian]

Bonsoir,

Aucun rapport ? tu prend 2 processus, les sémaphore te permet de donner la main à l'un, puis à l'autre, et sched_yield aussi ... imaginons dans le cas d'un fork .. ou de threads ...

Les sémaphores des IPC SysV sont l'implémentation UNIX des sémaphores de Dijkstra. Ils servent à provoquer la mise en attente d'un processus qui ferait appel à un sémaphore si les ressources que celui est censé représenter ne sont pas encore disponibles. L'application à la fois la plus simple et la plus répandue des sémaphores sont les mutex.

Les sémaphores UNIX ont la particularité d'être gérés par le noyau et de faire partie des IPC, c'est-à-dire que plusieurs processus distincts peuvent exploiter un même sémaphore, ce qui a beaucoup d'intérêt. Par contre, cela revient cher en temps système.

sched_yield(), par contre, n'a absolument rien à voir avec les sémaphores. C'est une fonction qui te permet de rendre volontairement la main au système. Celui préempte forcément ton processus soit si son quantum de temps est écoulé, soit s'il rend « de fait » la main en effectuant un appel système, à plus forte raison si celui-ci est bloquant et que cela fait repasser le processus dans l'état non prêt. C'est le cas, par exemple, lorsqu'il attend un caractère en provenance du clavier : pas la peine de le réveiller tant que l'utilisateur n'en a pas saisi un.

Faire un simple « sleep(1) » suffit donc à interrompre le fil de ton programme et à rendre temporairement la main au système, qui va en profiter pour donner une chance aux autres processus avant de revenir au tien. Mais ça a aussi l'inconvénient de bloquer ton programme pendant une seconde.

« sched_yield() » permet donc de « passer son tour » volontairement, mais sans bloquer ton programme. C'est intéressant lorsque tu fais un gros calcul sur une longue durée et que tu souhaites que le reste du système reste réactif entre temps (même si, dans ce cas précis, on va d'abord jouer sur la priorité du processus). C'est également pratique lorsque ton programme est multi-threadé, et que les différents threads utilisent cette fonction en coopérant.

Cela peut avoir beaucoup d'intérêt, enfin, si tu t'apprêtes à faire une opération que tu souhaites être atomique dans la mesure du possible. Passer son tour avant de commencer est un bon moyen d'être sûr de s'attribuer la totalité du quantum de temps pour l'opération en question.