• [^] # Re: Ordonnanceur?

    Posté par . En réponse à la dépêche Les promesses de la Native POSIX Threading Library et du prochain Kernel 2.6. Évalué à 10.

    mwais, bon, pour la notion de processus (je préfère dire tâche) et de thread, je vous conseille les défintions données dans le Mach Kernel Principles qui les explique très clairement AMHA: ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps. Je préfère voir ça comme deux choses distinctes: une tâche est une collection de ressources (espace d'addressage, fichiers ouverts, ...) dans laquelle s'exécute un plusieurs threads. Le problème, c'est que ce scheduleur doit essayer d'éviter les deadlocks entre les threads Ben, malheureusement, les algorithmes pour éviter les deadlocks sont loin d'être parfaits, et peu utilisables en pratique... Linux ne fait _rien_ pour éviter les deadlocks. Si je fais pthread_mutex_lock (mutexa); pthread_mutex_lock (mutexb); dans un thread et pthread_mutex_lock (mutexb); pthread_mutex_lock (mutexa); dans un autre, avec un peu de mal chance, mes deux threads vont être en deadlock, et Linux ne fera rien pour tenter de les sauver. Évidemment, lorsqu'on utilise des threads comme brique de base, il faut pouvoir commuter rapidement d'un processus à un autre Ben justement, non, la commutation de threads c'est beaucoup plus simple que la commutation de processus... changer de thread, c'est très simple, et ça peut même être fait uniquement en user-space (cf L4 et http://www.l4ka.org/publications/files/lazy-process-switching.ps ). C'est l'un des problèmes du noyau Linux actule où les notions de thread et de processus sont légèrement confondus (il n'y a pas de thread au sens propre, mais des processus pouvant partager certaines ressources, dont l'espace d'addressage).