La politique de gestion des threads

Puisque nous faisons appel au scheduler d'Unix, il est important de s'intéresser aux différentes possibilités offertes par celui-ci.

Premièrement, il est impératif de créer les pthreads en mode détachable
(PTHREAD_CREATE_DETACHED) dès leur création, car sans cela, l'axe qui aurait créé ce thread serait alors en attente de sa mort, et n'évoluerait donc plus.

De plus, lorsque l'on manipule les pthreads, nous avons la possibilité de signifier plusieurs types de politique de scheduling. Soit on "laisse Unix faire", soit on lui précise que l'on veut affecter des priorités aux threads (PTHREAD_EXPLICIT_SCHED). On a alors le droit (en mode root seulement) de donner des priorités différentes, allant de 1 à 99, grâce à la méthode sched_priority (le 0 désignant un thread non activable). De plus, nous devons définir le type de politique, avec la méthode pthread_attr_setschedpolicy, qui attend en paramètre soit SCHED_FIFO (realtime, first-in first-out), soit SCHED_RR (realtime, round-robin). La partie du scheduler d'Unix à laquelle nous avons accès grâce aux pthreads, n'est seulement composée du cas où plusieurs threads seraient en attente d'un mutex .

D'après le man [MAN_PTHREAD] : "Tout ordonnancement est préemptif : Si un processus avec une priorité statique plus élevée devient prêt [donc après un mutex par exemple], le processus en cours est interrompu et retourne dans sa liste d'attente. La politique d'ordonnancement détermine simplement l'ordre utilisé dans une liste de processus prêts avec des priorités statiques égales."

Dans les modes SCHED_FIFO et SCHED_RR , le scheduler partage le temps CPU équitablement entre les threads ayant les mêmes priorités maximales. Autrement dit, si deux threads ont une priorité de 10 et un thread a une priorité de 3, les deux threads seront alternativement exécutés jusqu'à ce qu'il y ait une opération d'entrée/sortie (bloquante) ou qu'ils ne soient préemptés par un thread (ou processus) de priorité supérieure. Utiliser plusieurs valeurs de priorités semble donc inutile.

Dans le seul de la préemption, le scheduler applique la politique que l'on vient de définir (soit le plus prioritaire en premier, soit un mode circulaire). Nous observerons dans la partie Résultats, les limites de ce pouvoir d'ordonnancement.