[SOS] Dilemme

David Decotigny david.decotigny at free.fr
Mar 12 Oct 17:23:26 CEST 2004


Bonjour,

Ce dilemme n'est pas si "etrange" que ca. Il s'agit plutot d'un des 
problemes centraux de la synchro, a peu pres aussi central que 
l'interblocage, voire meme l'inversion de priorite (qui pose probleme 
essentiellement en temps-reel, ou dans des cas tordus ou on definit une 
classe de priorites "idle").

A ma connaissance, le probleme de la suppression d'un thread qui possede 
des ressources de synchro n'a pas de solution ultime et systematique. Il 
y a plusieurs ecoles je pense, au moins deux :
   - 1ere ecole : on laisse le thread decider de ce qu'il doit faire : 
voir par exemple l'API Posix pour les threads, fonctions 
pthread_testcancel() et pthread_cleanup_push/pop()
   - 2eme ecole : c'est l'OS qui maintient la liste des ressources 
possedees par le thread. Sous Unix, ca ne se fait pas a l'echelle des 
threads a ma connaissances, mais a l'echelle des processus. Quand un 
processus est supprime (kill avec un signal), c'est l'OS qui libere les 
ressources qu'il utilisait (fichiers, sockets, mmap, IPC Svr4 [ipcs, 
semget and co]).

Bref a ma connaissance, dans ce genre de systeme, la suppression d'un 
thread n'est pas synchrone. Dit autrement : le thread qui en supprime un 
autre n'est pas bloque a attendre que le thread qu'il veut supprimer 
daigne se terminer. Le phenomene d'entrelacement dont tu parles, et qui 
n'est sans doute pas le seul probleme de ton approche synchrone, 
s'appelle plus couramment un "interblocage" (deadlock en anglais). 
Certains milieux autorises s'autorisent a penser que des philosophes 
amateurs de spaghettis en seraient morts.

Bonne journee,

-- 
David Decotigny -- http://david.decotigny.free.fr


Plus d'informations sur la liste de diffusion Sos