Discussion :

[Médinoc]

Ainsi, si on reparle de mon exemple, ma fonction déjà thread-safe et réentrante devient interrupt-proof si on protège l'empilement et le dépilement.
Mais cette protection ne sera pas par un mutex ou une CRITICAL_SECTION de Windows, car une routine d'interruption est incapable d'attendre qu'une ressource du même thread se libère*: Il faudra neutraliser l'interruption, ce qui sous Windows n'est pas possible en user-mode (mais pas grave, car sous Windows un thread utilisateur ne peut pas être interrompu par lui-même).

*Ce qui fait toute la différence entre multithread et programmation interruptible.

[Mac LAK]

ce qui sous Windows n'est pas possible en user-mode (mais pas grave, car sous Windows un thread utilisateur ne peut pas être interrompu par lui-même).

Certes, sous Windows, ce n'est pas le cas. D'ailleurs, sous Linux non plus.

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".

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.

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...

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.

[Médinoc]

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.

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.

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?

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?)

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.

[Mac LAK]

Faux: SIGALRM, SIGPOLL, etc. interrompent le thread de manière asynchrone et la routine de traitement est appelée dans le même thread.

Effectivement, j'avais oublié les signaux.
Faudrait donc voir quel mécanisme est utilisé par Cygwin pour faire ça sous Windows, ce qui rendrait donc un thread interruptible par lui-même, y compris sous Windows... Et cela rend encore plus important d'être intrinsèquement thread-safe, dans ce cas !

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.

Bloquer les IT est trop coûteux, tu as en général deux types de mutex utilisables : un "thread-only", et un mutex au niveau système qui masque les IT... Notamment l'IT du scheduler, et c'est un peu là le problème d'ailleurs.

Là, j'y comprends rien: Trop de sigles. Pourrais-tu expliquer plus?

Désolé : c'est une habitude de termes que j'ai pris avec WinCE, et j'ai du mal à m'en défaire je dois dire.
ISR : Interrupt Service Routine.
IST : Interrupt Service Thread.

Une ISR (appelée directement en réaction à une IT matérielle) traite l'IT de la façon la plus rapide possible, et passe les données / évènements à son IST associé (souvent, via une FIFO) qui permettra de non seulement libérer le contrôleur d'IT plus vite, mais également de pouvoir régler la "priorité" de traitement des données en question (via la priorité de l'IST, bien sûr).
En fonction de l'architecture et des actions à effectuer, les transferts "lourds" peuvent notamment être effectués par l'IST et non pas par l'ISR, ce qui limite encore plus le temps passé en contexte d'interruption.

Pour moi, le seul conteste, c'est "est-ce qu'on fait de la prog interruptible ou non?"

Yep, mais dans ce cas, tu es en programmation défensive : tu ne te protèges que contre les risques connus, en réaction à une fonction qui n'est pas intrinsèquement thread-safe. Donc, potentiellement, tu laisses des portes ouvertes à une concurrence malheureuse, et c'est le genre de truc franchement infernal à débugger : en effet, il est normal de considérer qu'une fonction "protégée" contre la concurrence l'est réellement, et que l'objet de synchronisation utilisé est "le bon". On n'en vient en général à suspecter le mode de protection qu'en dernier ressort... après un (trop) long délai passé à rechercher un bug dans du code qui n'y était pour rien.

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.

La notion de thread-safety ne devrait, normalement, PAS faire mention du fait que ce soit un autre thread (ou le même !!) qui interrompt ton fonctionnement.

Si tu peux garantir un fonctionnement thread-safe quel que soit le thread interrompant ton exécution, y compris "toi-même", alors tu es intrinsèquement thread-safe. Sinon, tu peux toujours avoir un cas vicieux d'utilisation qui provoquera un bug.

Certes, ce cas peut ne jamais se produire si le code est suffisamment testé et qu'il n'évolue pas. S'il évolue et/ou est réutilisé, les (mal)chances de voir le bug se produire augmentent significativement.

[Médinoc]

La notion de thread-safety ne devrait, normalement, PAS faire mention du fait que ce soit un autre thread (ou le même !!) qui interrompt ton fonctionnement.

C'est là que nos opinons diffèrent, et je ne pense pas que tu arriveras à me faire changer d'avis.

[Mac LAK]

C'est là que nos opinons diffèrent, et je ne pense pas que tu arriveras à me faire changer d'avis.

En fait, le problème est que c'est une logique d'optimisation et non pas de conception, je t'explique ça plus en détail.


Considère une application MT, sans bugs, et fonctionnant de façon correcte et attendue. Ses fonctions threadées sont intrinsèquement thread-safe, même si elles sont (éventuellement) plus lentes. Cette application possède l'immense avantage d'être stable, portable, et la plus indépendante possible de son contexte global d'exécution, ou des ajouts qui pourraient lui être fait sans le savoir (typiquement, plugins et autres sous-DLL plus ou moins bien connues à l'avance).

Maintenant, pour une raison X, tu dois l'optimiser. C'est à ce moment, et à ce moment seulement, que tu dois réfléchir au fait de voir qui interrompt qui, et comment, de façon à faire sauter des prises de mutex "inutiles". C'est également à ce niveau que tu vas faire sauter, par exemple, les protections des sous-fonctions, en considérant qu'il y a déjà une protection à plus haut niveau.

Le problème, c'est que ce processus est non seulement laborieux, mais en plus, casse-gueule au possible. Ce type d'optimisation, bien que très efficace, est coûteux en temps de développement et en maintenance, car on rend l'application extrêmement vulnérable aux modifications des divers contextes plus ou moins bien définis.

Et décemment, je ne peux pas conseiller aux gens de partir sur un dév MT dans ce cas de figure, surtout que la plupart des débutants ne seront pas capables d'appliquer correctement le niveau de protection "au dessus"... D'où le fait que je préconise de réfléchir de façon globale, sans "savoir" quel thread interrompt qui.

[Médinoc]

Ce n'est pas tellement ce genre de logique que j'ai, c'est plus:

• Se protéger des autres: thread-safety
• Se protéger de soi-même: réentrance/empilement et interrupt-safety.

N'oublie pas qu'à un niveau au-dessus des considérations de scheduling, un thread n'en interrompt jamais un autre: Il tourne en même temps, touche à des ressources disputées, mais n'interrompt jamais l'exécution d'un autre à un endroit où l'autre ne l'a pas "prévu" (comme une attente sur un mutex).

[Mac LAK]

Ce n'est pas tellement ce genre de logique que j'ai

Disons que pour moi, c'est une logique au contraire fondamentale, vu que c'est une des causes première des problèmes de MT que je rencontre... Une partie de mon boulot consiste à optimiser du MT qui peut l'être (gain de perfs), et l'autre à blinder un code qui ne l'est pas. Les deux activités sont fondamentalement différentes, malgré qu'elles touchent au même "domaine" : l'une "défait", et l'autre "fait" les protections.

N'oublie pas qu'à un niveau au-dessus des considérations de scheduling, un thread n'en interrompt jamais un autre: Il tourne en même temps, touche à des ressources disputées, mais n'interrompt jamais l'exécution d'un autre à un endroit où l'autre ne l'a pas "prévu" (comme une attente sur un mutex).

C'est un point de vue que je trouve "dangereux" : en pratique, tu ES réellement soumis à un descheduling pouvant arriver n'importe quand. La seule chose que fait un mutex, c'est de te garantir qu'une fonction d'un thread utilisant le même mutex ne fera pas partie de la liste des threads pouvant t'interrompre... Mais pas plus ! N'oublie pas le fait qu'un thread possède un quantum de temps maximal avant de se faire descheduler "de force", qu'il attende ou pas un quelconque objet de synchro... Et c'est souvent lors de ce type de descheduling que se produisent les pires problèmes.

Et quand je vois le nombre hallucinant d'erreurs qui se résument, au final, à "Ah bon ? C'était pas une opération atomique ?", je crois très dangereux de laisser croire que l'on ne peut pas être interrompu au "pire moment"... Car c'est en général à ce moment précis, loi de Murphy oblige, que ça va se produire.

[Médinoc]

Une opération dont on a besoin qu'elle soit atomique rentre dans la catégorie "ressources disputées" pour moi, d'où nécessité de protection (mutex, fonctions Interlocked, etc.).

Edit: Et surtout, pour moi ça compte comme "pouvant arriver en même temps" plutôt que "pouvant interrompre". Et avec le multiprocesseur, c'est de plus en plus vrai.

[Mac LAK]

Une opération dont on a besoin qu'elle soit atomique rentre dans la catégorie "ressources disputées" pour moi, d'où nécessité de protection (mutex, fonctions Interlocked, etc.).

C'est la fonction elle-même qui peut avoir besoin d'être atomique, et non pas seulement l'accès aux ressources individuelles...

Edit: Et surtout, pour moi ça compte comme "pouvant arriver en même temps" plutôt que "pouvant interrompre". Et avec le multiprocesseur, c'est de plus en plus vrai.

Justement : c'est encore pire quand l'exécution est très exactement simultanée, par rapport à une "simple" interruption... Parce que tu risques, en plus, d'être soumis à des aléas imposés par le matériel, notamment vis-à-vis de l'accès simultané au même emplacement de mémoire partagée.

[Médinoc]

Bien sûr. Mais cela ne rend pas mon exemple de TLS non thread-safe (vu que ses données n'appartiennent qu'à son propre thread) ni non réentrant. Non interrupt-safe absolument, par contre.

[Mac LAK]

Bien sûr. Mais cela ne rend pas mon exemple de TLS non thread-safe (vu que ses données n'appartiennent qu'à son propre thread) ni non réentrant. Non interrupt-safe absolument, par contre.

Cela dépend de quel thread-safe on parle... Pour moi, c'est tacitement de l'intrinsèque, et donc ta fonction n'est (toujours pour moi) pas thread-safe, même et y compris si elle peut, malgré tout, être utilisée dans un contexte MT sans provoquer de bugs.

Pour prendre une analogie, c'est comme la sécurité d'un outillage : tu peux très bien n'avoir aucun accident avec un outil qui n'est pas "sûr" (ex : scie circulaire sans volet de protection). Cela ne rend pas l'outil sûr pour autant, c'est juste que celui qui s'en sert n'est pas inconscient. Par contre, un outil sûr peut être utilisé même par un inconscient sans provoquer d'accident...

C'est pareil avec la notion de thread-safety : ce n'est pas parce qu'une fonction marche dans un contexte MT qu'elle est thread-safe, c'est simplement qu'elle est utilisée de façon contrôlée. Comme je te le disais, c'est une méthode d'optimisation des systèmes MT, mais dans un tel cas de figure on sabre volontairement tout ou partie du côté thread-safe d'une fonction pour la rendre plus performante.

[Médinoc]

Mais ma fonction marche dans tous les contextes MT qui ne causent pas des interruptions par le même thread, elle est fait donc partie du sous-ensemble des fonctions thread-safe mais non interrupt-safe.

[Mac LAK]

Mais ma fonction marche dans tous les contextes MT qui ne causent pas des interruptions par le même thread, elle est fait donc partie du sous-ensemble des fonctions thread-safe mais non interrupt-safe.

Relis la phrase soulignée dans mon post précédent... Le fait que "ça marche" est une condition nécessaire, mais non suffisante (je dirais même que c'est plutôt le minimum syndical). C'est comme les bugs et les failles de sécurité : ce n'est pas parce que tu ne les déclenches pas qu'ils n'existent pas !

[Lavock]

Pour ma part, je n'utilise jamais de mutex ne pouvant pas être lockés plusieurs fois par le même thread : cela pose de trop gros problèmes lors du chaînage d'appels de fonctions, et des possibilités de descheduling si l'on relâche/reprends un mutex non-récursif... C'est plutôt le concept de "mutex non-récursif" qui me semble aberrant à utiliser de façon générale, du moins en dehors du code interne des primitives des objets de synchronisation... Même un objet aussi simple que le CRITICAL_SECTION Win32 est récursif !

Entièrement d'accord, cela dit, cela sous-entend que l'on peut faire du thread-safe non réentrant.

Désolé : c'est une habitude de termes que j'ai pris avec WinCE, et j'ai du mal à m'en défaire je dois dire.
ISR : Interrupt Service Routine.
IST : Interrupt Service Thread.

ISR est une appelation courante. L'autre, on trouve l'appellation DSR (Defered Service Routine) aussi. Je sais pas quel est la plus standard, mais je trouve le second terme plus claire.

[Mac LAK]

Entièrement d'accord, cela dit, cela sous-entend que l'on peut faire du thread-safe non réentrant.

Je dirais plutôt que ça sous-entend qu'avec des mutex non-récursifs, on va faire du thread-safe qui ne l'est pas vraiment, ou des deadlocks à foison (ce qui n'est pas thread-safe non plus !)...

ISR est une appelation courante. L'autre, on trouve l'appellation DSR (Defered Service Routine) aussi. Je sais pas quel est la plus standard, mais je trouve le second terme plus claire.

J'ai l'impression que chaque OS (voire chaque boîte !) a plus ou moins sa propre terminologie à ce sujet... Bah, tant que l'on explique qui correspond à quoi, ce n'est pas trop grave encore.