[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