Deux options sont possibles pour l'ordonnanceur : soit il laisse toujours le thread qui s'exécute libre de garder le processeur tant qu'il le désire, soit il peut, dans certaines situations, le forcer à s'arrêter. Dans le premier cas, on parle de stratégie coopérative, tandis que la stratégie correspondant au second cas est dite préemptive. Dans une stratégie coopérative, les threads doivent obligatoirement coopérer avec les autres et éviter de monopoliser le processeur indéfiniment. En effet, dans le cas contraire, le système risque de se bloquer complètement puisque l'OS lui-même ne peut plus s'exécuter. C'est ce qui arrive parfois avec les OS anciens comme Windows 3.1 ou les premières versions de MacOS. Dans ces situations, l'unique solution est de "rebooter" la machine. L'évolution des OS a naturellement conduit à des stratégies préemptives dans lesquelles un thread non-coopératif ne risque pas de bloquer le système tout entier et tous les OS modernes utilisent maintenant, à la suite d'Unix, des stratégies préemptives.

Un ordonnanceur préemptif peut très bien retirer le processeur à un thread (on dit alors que le thread est préempté) en plein milieu du traitement d'une donnée qui risque ainsi d'être laissée dans un état incohérent. L'outil utilisé pour protéger les données est appelé verrou; intuitivement, un thread commence par fermer un verrou avant d'accèder à une donnée protégée, ce qui interdit aux autres threads de pouvoir y accéder même s'ils recoivent le contrôle de l'ordonnanceur. Le thread qui avait fermé le verrou ne le rouvre que lorsqu'il a fini de transformer la donnée, ce qui permet alors aux autres threads d'accéder à leur tour à la donnée protégée.

Malheureusement, des situations peuvent apparaître dans lesquelles certains threads ne peuvent plus progresser, quoique qu'il advienne ; ces situations sont appelées deadlocks (traduits en français par étreintes fatales ; on comprend que, ici aussi, on préférera garder le terme anglais...). Le dessin suivant montre une situation de deadlock : sur la partie gauche du dessin, on voit la situation de départ : deux threads sont en concurrence pour deux verrous. La partie droite montre la situation de deadlock : chacun des threads a fermé un verrou et essaie de fermer l'autre ; les deux threads ne peuvent plus progresser par eux-mêmes et les moyens connus de sortir de cette situation sont très coûteux.

Les deadlocks sont véritablement une des "plaies" principales de la programmation concurrente, en particulier parce que, dans le cas général, il est impossible de déterminer à l'avance si un programme peut ou non tomber dans un deadlock (il s'agit d'un problème indécidable, comme l'est celui de déterminer si l'exécution d'un programme termine ou boucle indéfiniment).

Des priorités peuvent être associées aux threads, pour guider l'ordonnanceur dans le choix des threads à exécuter : l'ordonnanceur choisit toujours, en effet, un thread de priorité maximale parmi ceux qui peuvent être exécutés. Ainsi, en associant des priorités différentes aux threads, on peut espérer contrôler l'ordre dans lequel ils sont exécutés. A noter cependant que, lorsque plusieurs threads de même priorité peuvent être exécutés, l'ordonnanceur est libre de choisir n'importe lequel parmi ceux-ci (son comportement est dit non-déterministe).

En pratique, les priorités sont difficiles à utiliser et leur utilisation peut conduire à des situations connues sous le nom "d'inversions de priorités" dans lesquelles un thread de basse priorité interdit à un thread de haute priorité de s'exécuter. C'est une de ces situations qui a failli faire échouer la mission Mars Pathfinder, en 1997. Le petit robot posé sur Mars se mettait en effet à rebooter sans arrêt lors des transmissions radio vers la Terre. Cela était du à un phénomène d'inversion de priorité entre les 3 threads que le robot avait à exécuter : le thread de haute priorité qui réglait le fonctionnement du robot ne pouvait pas s'exécuter parce que le thread de basse priorité d'acquisition des données possédait un verrou dont il avait besoin ; mais le thread de moyenne priorité de communication avec la Terre prenait alors le processeur car il n'avait pas besoin du verrou et était plus prioritaire. Ainsi, on obtenait une situation où le thread de priorité basse interdisait au thread de priorité haute de s'exécuter et où le thread de priorité moyenne pouvait en profiter pour prendre le processeur. Comme la communication avec la Terre dure longtemps, un timer détectait un problème grave, puisque la tâche prioritaire n'était pas exécutée dans les temps, et rebootait purement et simplement le système...

Diverses propositions de threads coopératifs ont été faites récemment. L'une d'elles, appelée FairThreads, est développée dans le projet MIMOSA, commun à l'École des Mines de Paris et à l'INRIA et soutenu par France Télécom R&D. Elle consiste en des threads équitables (fair) exécutés par des ordonnanceurs spécialisés leur donnant des possibilités égales d'accès au processeur. Les threads équitables peuvent être contrôlés finement, permettant ainsi à l'utilisateur de coder ses propres stratégies d'exécution. De plus, les threads équitables peuvent communiquer par des événements diffusés, ce qui simplifie la programmation. Enfin, les programmes utilisant ces threads sont déterministes : leur résultat est indépendant de l'ordonnanceur de la machine qui les exécute, ce qui n'est généralement pas le cas avec des threads standards. Le déterminisme facilite grandement le portage et le debugging des programmes.

Reprenons l'exemple des deux threads sinus et cosinus précédents. En utilisant des threads équitables, on obtient un cercle sans avoir à introduire de synchronisation particulière : la synchronisation entre les deux threads résulte en effet automatiquement du caractère équitable de l'exécution. De même, l'ajout d'un troisième thread ayant également un comportement en cosinus donne immédiatement la courbe de Lissajous attendue :

L'ordonnanceur équitable synchronise en effet automatiquement les trois threads, et ceci sans avoir à changer quoi que ce soit aux deux threads initiaux.

Les FairThreads ont été portés en Java, en C et en Scheme (dans le système Bigloo). Un serveur Web utilisant les FairThreads a en particulier été codé de manière extrêmement simple et modulaire en Scheme.

L'implémentation en C des FairThreads utilise la librairie pthread. Dans cette version, il est possible de mélanger les fair threads coopératifs avec des threads natifs, soumis au contrôle de l'OS préemptif. Cette version des fair threads permet de profiter des architectures multiprocesseurs (SMP).

Nous sommes également, dans le projet MIMOSA, en train d'étudier comment utiliser les FairThreads, ou plus généralement la programmation réactive, pour la programmation concurrente de systèmes embarqués avec de faibles ressources (les Personal Digital Assistants, par exemple).

Enfin, il existe également une autre approche, appelée réactive-synchrone, qui permet une programmation simple et efficace de la concurrence, en résolvant certains problèmes des threads. Plusieurs équipes françaises, à l'INRIA, au CNRS et à l'École des Mines de Paris ont développé et utilisent des langages construits sur cette approche, dont les plus connus sont les langages synchrones Esterel, Lustre et Signal. La programmation synchrone est principalement utilisée pour les systèmes embarqués (comme ceux des avions) et pour les systèmes sécurisés (conduite de centrale nucléaire, par exemple, dans le cas de Lustre).