Multithreading

[NicolasFloquet]

Voilà, il fallait que ce soit dit un jour alors je fais moi même le ticket: il nous faut du multithreading! Deux motivations pour cela: -Pour les IHM, c'est quand même un peu mieux -Le besoin de thread kernel est très important. Par exemple si drivers qui ont besoin de faire des attentes pouvaient avoir des threads, on pourrait facilement implémenter des attentes passives. D'autre part, les thread kernel seront indispensable pour implémenter certaines features (la pile réseau par exemple).

Première réflexion sur l'implémentation: Actuellement, la structure de processus contient directement l'état d'exécution (registres) du process et d'autres informations. Quand le processus est choisis par l'ordonnanceur, on sauvegarde l'état du process courant et on charge celui du nouveau. Une premier implémentation simple serait que la structure du processus contienne une liste de thread qui auraient chacun leur état d'exécution propre. Lors de l'ordonnancement, un premier ordonnanceur choisis le processus à exécuter, puis un deuxième ordonnanceur (avec éventuellement une politique différente) viendrait choisir, au sein de ce process, le thread à exécuter. La création d'un processus est du coup presque inchangée, la seule problématique sera de trouver dynamiquement une place pour les piles des threads qui seront créés au cours de l'exécution.

Donc c'est une première idée, à creuser, j'aimerais bien des retours/idées/remarques

[MaximeCheramy]

Est-ce qu'il n'y a pas deux choses similaires mais différentes en fait ? C'est une vraie question, je ne sais pas du tout.

• La première ce seraient les "processus légers" qui serait en fait un truc userspace. C'est la librairie que tu utilises qui gérerait ça. Et je m'imagine un fonctionnement tel que tu le décrit, à savoir un second ordonnanceur qui prend la main quand le premier la lui donne. Chaque thread aurait sa propre stack. Mais est-ce possible de garder tout le truc en userspace ou faut-il le lier au kernel ?
• Bon et les threads kernels.

[NicolasFloquet]

Ben je vois pas trop comment gérer ça uniquement au niveau userspace. Par exemple, cet ordonnanceur de thread doit avoir le pouvoir de passer d'userspace en kernel space (exemple, si le thread actuel est en userspace, et qu'on switch vers un thread qui a été interrompu pendant un appel système). ça, il faut être en kernel space pour le faire simplement je pense. Après on peut imaginer aussi qu'un processus ne peut faire qu'un seul appel système à la fois ce qui est très envisageable et facile à faire (un mutex dans syscall() ). Enfin je vois pas trop comment gérer un ordonnanceur userspace (par qui il est appelé? quand? comment il récupère l'état du thread courant?)

[MaximeCheramy]

Le principal problème de le faire en userspace serait de pas pouvoir interrompre un thread pendant un appel système. Ensuite pour le reste c'est jouable à l'aide de timers je pense. Mais oui c'est peut-être pas une bonne idée. À voir ce dont on a besoin côté kernel.

Tiens, je viens de tomber sur http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library qui parle de problèmes avec l'ancienne implémentation des threads Linux et en quoi ceux posix sont mieux... Ça peut être enrichissant à comprendre.