Citation:
Envoyé par
Mac LAK
sous Linux non plus.
Faux: SIGALRM, SIGPOLL, etc. interrompent le thread de manière asynchrone et la routine de traitement est appelée dans le même thread.
Citation:
Tu as cependant des OS où la notion d'user-mode n'existe pas, et qui sont pourtant multitâches et préemptifs... Et les ISR peuvent te péter à la tête n'importe quand : en pratique, cela revient à avoir un Windows (ou Linux) qui ne serait QUE en kernel-mode. Ou cela revient à développer du code en kernel-mode, y compris sur des OS "protégés".
Donc là, tu es en programmation interruptible. Donc, tu dois pouvoir désactiver les interruptions dans tes sections critiques, et ce n'est pas un mutex qui fera ça.
Citation:
Après, le souci majeur de "collaboration" entre le niveau IT et le niveau thread est surtout lié aux librairies utilisées : normalement, tu ne dois JAMAIS utiliser les librairies de l'un dans l'autre, ni avoir d'éléments logiciels "communs". Le seul thread qu'une ISR doit savoir gérer, c'est son IST correspondant, et réciproquement.
Là, j'y comprends rien: Trop de sigles. Pourrais-tu expliquer plus?
Citation:
Après, si l'on doit préciser que l'on est en mode user ou en mode kernel, ça devient du contexte d'appel, donc il faudrait le rajouter en paramètre à la fonction, vérifier la réelle isolation des deux contextes (pas garanti, ça...), etc. : ça va devenir assez lourd à expliquer, je pense, et ça ne changera pas le fait qu'une fonction qui n'est pas intrinsèquement thread-safe ne le sera toujours pas après, même après cette précision de contexte...
Pour moi, le seul conteste, c'est "est-ce qu'on fait de la prog interruptible ou non?" Et on se protège de chaque menace de la manière qu'il faut:
- Autres threads: Mutexes et TLS (thread-safety)
- Appels "normaux" du même thread: Contexte public ou empilable (réentrance)
- Interruptions dans le même thread: Désactivation des interruptions lors de l'empilement (interrupt-safety?)
Citation:
A mon avis, le plus important est de bien distinguer que tu as deux niveaux de thread-safety : celle au niveau du contexte d'utilisation (= une fonction qui marche correctement dans un processus MT), et celle au niveau de la conception du code de la fonction (= une fonction qui est conçue pour être intrinsèquement thread-safe, peu importe comment elle est utilisée).
Faut être réaliste, le premier cas est plus fréquent que le second... hélas.
Pour moi, quand le danger vient du même thread, cela ne rend pas la fonction non-intrinsèquement-thread-safe. On avait déjà thread-safety et réentrance, et pour moi l'interrupt-safety est une troisième dimension.