Discussion :

[Médinoc]

Je reformule : tu n'as pas de garantie qu'il soit complet, ce contexte... Si tu préfères, tu ne sais pas si ta callback est réentrante ou pas. Si elle n'est pas réentrante, toute fonction l'utilisant ne peut PAS être réentrante.

Pour moi, elle est réentrante si on peut l'appeler de la callback sans problème, non?
C'est justement de la callback elle-même que vient le risque d'utilisation récursive, donc si la fonction n'appellait pas de callback, je n'aurais pas de besoin de d'empiler ma variable persistante...

Typiquement, dans le code que tu montres, tu présupposes (tacitement, vu l'absence de SC) que l'affectation de la globale ou son incrémentation sont atomiques

Non, je présuppose que la globale n'est pas une vraie globale, mais du TLS (d'où le __declspec(thread) parce que j'avais la flemme d'écrire le code de gestion explicite du TLS dans un simple code d'exemple). J'aurais aussi bien pu "supposer que l'expérience de déroule dans le cadre d'un programme monothread"...

[screetch]

j'aurai envie d'etre plus strict que ca avec ta reentrance medinoc.
le problème c'est que ta fonction elle-même est réentrante, mais si tu lui passes une callback non réentrante, qui se rappelle elle-même?

une fonction est réentrante si toute les fonctions qu'elle appelle sont aussi réentrantes.

[Mac LAK]

Pour moi, elle est réentrante si on peut l'appeler de la callback sans problème, non?

Oui, si c'est bien "quel que soit le cas de figure"... Notamment de l'appeler avec les mêmes paramètres.
Mais tu n'as PAS le source de la callback en question pour le prouver, c'est ça le problème... Donc, tu ne peux pas affirmer que la fonction est intrinsèquement réentrante.

Non, je présuppose que la globale n'est pas une vraie globale, mais du TLS

Cela ne change pas le problème : si tu réentres (via la callback) dans ta fonction, tu vas taper dans la même valeur.
Or, même si c'est probablement le cas avec un int, tu ne peux pas garantir que l'utilisation de cette globale ne posera pas de problèmes s'il y a récursion.
Dans le principe GLOBAL, il y a un risque, donc elle n'est pas réentrante (principe de précaution).

Après, je le redis, tu as trois tonnes d'implémentations de fonctions non-réentrantes et/ou non-thread-safe qui marchent très bien avec de la concurrence à fond les ballons, parce que l'on s'est mis dans un cas spécifique permettant de ne pas déclencher les problèmes intrinsèques des fonctions. Pour moi, ton exemple est typiquement dans cette catégorie : fonction non-réentrante d'un point de vue théorique, mais qui n'a pas de problème dans son contexte d'utilisation bien cadré.

[3DArchi]

Salut,
@Mac Lak : je suis d'accord, nos 2 définitions sont plus ou moins équivalentes. Et je ne vois pas en quoi wiki ne dit pas la même chose que nous : la réentrance est liée à l'interface de la fonction puisqu'on y exporte le contexte, et thread-safety est interne à la fonction. Là où wiki se fourvoie à mon sens c'est quand il dit que réentrance implique thread-safety.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int f(int &i)
{
   return ++i;
}

Voilà pour moi une fonction réentrante mais pas thread-safe.

[jamin]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int f(int &i)
{
   return ++i;
}

Voilà pour moi une fonction réentrante mais pas thread-safe.

Elle n'est pas thread-safe si on lui passe une variable globale ou statique, on est d'accord ?
En effet, si on lui passe une variable locale du thread, ça ne posera pas de problème !

[Mac LAK]

Et je ne vois pas en quoi wiki ne dit pas la même chose que nous : la réentrance est liée à l'interface de la fonction puisqu'on y exporte le contexte, et thread-safety est interne à la fonction.

Tout comme toi, ce n'est pas ce point-là de l'article que je conteste.

Là où wiki se fourvoie à mon sens c'est quand il dit que réentrance implique thread-safety.

Exactement : pour moi, c'est l'inverse.

Voilà pour moi une fonction réentrante mais pas thread-safe.

En effet, on est d'accord.

Elle n'est pas thread-safe si on lui passe une variable globale ou statique, on est d'accord ?
En effet, si on lui passe une variable locale du thread, ça ne posera pas de problème !

Ce qui revient au même cas que celui de Médinoc : tu peux l'utiliser avec des threads concurrents sans avoir de problèmes, et comme tu le dis toi-même, cela dépend de la portée de la variable passée en paramètre.
Mais ça ne veut pas dire qu'elle est intrinsèquement thread-safe : passe la même donnée "i" via deux threads concurrents, et tu t'exposes à des problèmes.

[Lavock]

Exactement : pour moi, c'est l'inverse.

C'est là ou je suis pas d'accord ! On peut avoir une fonction thread-safe mais non-réentrante oO !

[screetch]

je me demande si on a pas besoin de plus de "tags" a la const en C++; un tag "global" qui montrerait qu'une variable est globale, et si une fonction veut modifier une variable marquée globale alors elle doit le dire de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
int f(int &i) // reentrante
{
   return ++i;
}
int f(global int &i) // non reentrante
{
   return ++i;
}

ainsi, si un objet, meme si c'est un pointeur, est local, alors tout ce qu'il pointe est local (sauf si cela contient la mention "global")
et l'inverse : si un pointeur est global, tout ce qui est pointé l'est aussi. Un peu comme le const.

le fait que par défaut une donnée soit locale et pas globale a aussi un sens
et il serait impossible de passer de local a global ou de global a local car on a aucune garantie.
Aussi, si un objet est local, on sait tout de suite qu'il n'a pas a etre protégé de "race conditions"

[Médinoc]

On peut même avoir ceci:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f(int *pi, int *pj)
{
	++(*pi);
	InterlockedIncrement(pj);
}

Cette fonction est réentrante, utilise pj de manière thread-safe, mais pi de manière non-thread-safe.

En programmation objet, ça se rencontre assez souvent dans des cas où pj est this.

[screetch]

j'avoue que j'ai beaucoup de problème avec votre définition ultra laxiste de "réentrante"
a partir du moment ou il y a un pointeur ou une référence alors une fonction n'est plus réentrante selon moi. Mais ca peut etre juste mon interpretation. Mais cacher un contexte sous le tapis puis dire que tout est local, je trouve ca un peu abusé.

[JolyLoic]

je me demande si on a pas besoin de plus de "tags" a la const en C++; un tag "global" qui montrerait qu'une variable est globale, et si une fonction veut modifier une variable marquée globale alors elle doit le dire

Je crois que c'est un peu l'objectif des propositions pour avoir la notion de fonction "pure" (mais formulée dans l'autre sens). Le gros problème étant que ça ne se marie pas forcément bien avec la compilation séparée.

[Mac LAK]

C'est là ou je suis pas d'accord ! On peut avoir une fonction thread-safe mais non-réentrante oO !

T'as un exemple ?
Je pense que si tu en donnes un, on pourra voir que soit elle n'est pas thread-safe, soit elle est en fait réentrante...

Pour info : protéger une fonction par un mutex qui lui est propre, et acquis sur la totalité de l'exécution de la fonction (typiquement, un mutex static local acquis en RAII), rend la fonction réentrante...

En effet, quels que soient les paramètres de la fonction et le contexte d'exécution de l'appelant, la fonction peut s'exécuter en parallèle, car son contenu devient atomique (et les opérations atomiques n'ont jamais été une cause de problème en parallélisme, bien au contraire).
Or, le mutex étant pris et relâché au sein même de la fonction, tu as bel et bien, à un instant T, les deux fonctions en exécution simultanée (une qui "bosse", l'autre bloquée sur la prise de mutex)... Ce qui la rend réentrante, ainsi que thread-safe bien entendu.

L'exemple serait faux (et la fonction ni thread-safe, ni réentrante) si tu encadrais l'appel de la fonction par la prise d'un mutex : dans ce cas de figure, c'est l'appelant qui est thread-safe, et non pas la fonction appelée.

Cette fonction est réentrante, utilise pj de manière thread-safe, mais pi de manière non-thread-safe.

Effectivement : réentrante, mais pas thread-safe... Et non pas le contraire.

[screetch]

strtok, protégée avec un gros mutex, n'est toujours pas réentrante. ton affirmation est globalement fausse.

[Mac LAK]

strtok, protégée avec un gros mutex, n'est toujours pas réentrante. ton affirmation est globalement fausse.

L'interface de strtok n'est pas réentrante car elle ne fournit pas son contexte... Bien qu'il y aie des implémentations, telle que celle de Visual, qui fournisse une version réentrante.

Intrinsèquement, strtok n'est donc pas réentrante, c'est d'ailleurs un cas classique de "mauvaise fonction". Après, suivant l'implémentation, elle peut le devenir : augmentation de la signature pour prendre le contexte, contexte stocké dans le TLS et mutex global sont par exemple de bonnes façons d'y arriver.

Après, si ton implémentation de strtok, malgré son "gros mutex", possède un contexte global unique (pas dans le TLS, donc), alors elle n'est ni thread-safe, ni réentrante. Si son contexte est local au thread, alors elle devient réentrante et thread-safe.

Si tu veux me prouver qu'une fonction est thread-safe tout en n'étant pas réentrante, merci d'en poster le code source.

[Médinoc]

Si tu veux me prouver qu'une fonction est thread-safe tout en n'étant pas réentrante, merci d'en poster le code source.

L'implémentation Microsoft de toutes les fonctions non-réentrantes de la bibliothèque C: strtok(), strerror()...
Pourquoi? Parce que cette implémentation utilise des contextes locaux au thread, à grand renfort de TLS. Mais ces fonctions n'en deviennent pas réentrantes pour autant.

[3DArchi]

De mon expérience, la réentrance est à la base une contrainte des gestionnaires d'interruptions et à peu à voir avec la programmation concurrente. Il s'agit surtout de garantir qu'un tel gestionnaire peut être interrompu de manière sûre. Une fonction doit être réentrante pour pouvoir être appelée lors du traitement de la première ou second interruption.
Sans y avoir trop réfléchi, je me demande si l'articulation entre réentrance et thread-safety (pour les cas non triviaux) ne se joue pas selon la façon dont le mutex est géré et selon son type (possibilité d'être locké 2 fois dans le même thread ou pas).

[screetch]

Pour info : protéger une fonction par un mutex qui lui est propre, et acquis sur la totalité de l'exécution de la fonction (typiquement, un mutex static local acquis en RAII), rend la fonction réentrante...

Après, si ton implémentation de strtok, malgré son "gros mutex", possède un contexte global unique (pas dans le TLS, donc), alors elle n'est ni thread-safe, ni réentrante

tu te contredis la. Je crois que tu n'as pas compris le problème de la réentrance

[Mac LAK]

L'implémentation Microsoft de toutes les fonctions non-réentrantes de la bibliothèque C: strtok(), strerror()...
Pourquoi? Parce que cette implémentation utilise des contextes locaux au thread, à grand renfort de TLS. Mais ces fonctions n'en deviennent pas réentrantes pour autant.

Si, pourtant : elles le sont, car avec un mutex, elles ne peuvent plus être (réellement) interrompues par elles-mêmes, et deviennent thread-safe (et réentrantes grâce au TLS). Et sans les mutex, et malgré le TLS, elles ne sont plus réellement thread-safe : en effet, l'utilisation du TLS te garantit que la variable est unique pour chaque thread, mais pas qu'elle sera protégée en cas d'accès concurrent !!

Même si je te concède bien volontiers qu'il sera dans ce cas assez difficile, hors d'un ISR, de pouvoir déclencher le cas d'erreur... Mais ce n'est pas parce qu'une fonction "résiste" à du multi-threading qu'elle est intrinsèquement thread-safe !

De mon expérience, la réentrance est à la base une contrainte des gestionnaires d'interruptions et à peu à voir avec la programmation concurrente. Il s'agit surtout de garantir qu'un tel gestionnaire peut être interrompu de manière sûre. Une fonction doit être réentrante pour pouvoir être appelée lors du traitement de la première ou second interruption.

C'est également un autre cas de réentrance, qui certes n'est jamais vu par ceux qui ne touchent jamais au bas niveau. Mais on en revient peu ou prou à la même chose : a-t-on un contexte explicite, ou un contexte implicite ? En cas de contexte implicite, est-ce que le précédent est sauvegardé, et intact, par le déclenchement d'une ISR ? Mais là, ça dépend aussi du matériel, donc il n'est pas forcément possible de dire, d'après son unique code source, si une ISR est réentrante ou pas sans savoir comment se comporte le contrôleur d'interruptions...

Sans y avoir trop réfléchi, je me demande si l'articulation entre réentrance et thread-safety (pour les cas non triviaux) ne se joue pas selon la façon dont le mutex est géré et selon son type (possibilité d'être locké 2 fois dans le même thread ou pas).

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 !

Après, il est évident qu'utiliser un mutex non-récursif ne peut PAS rendre la fonction ni réentrante, ni thread-safe, vu que la moindre tentative de réentrance aboutit à un deadlock direct... J'ose espérer que personne sur ce topic n'a osé imaginer que le terme "mutex tout court" pouvait recouvrir un mutex NON-récursif !

[Médinoc]

Attends une minute: Pour moi, si une fonction est vulnérable à une interruption, ce n'est pas une question de thread-safety: On sort de la programmation multithread et on passe à de la programmation interruptible, qui est un tout autre domaine, avec des protections différentes (masquage de signal, etc.)

Tant qu'on n'est pas en programmation interruptible, une fonction ne peut être "dérangée" qu'aux moments où elle le veut bien: Appels de fonctions callback, SendMessage() de Windows, etc.

[Mac LAK]

Attends une minute: Pour moi, si une fonction est vulnérable à une interruption, ce n'est pas une question de thread-safety: On sort de la programmation multithread et on passe à de la programmation interruptible, qui est un tout autre domaine, avec des protections différentes (masquage de signal, etc.)

Ce n'est pas un domaine si différent que ça, en fait, la seule différence est qu'au niveau ISR, la plate-forme matérielle est un des éléments du contexte global de chaque fonction.

Tant qu'on n'est pas en programmation interruptible, une fonction ne peut être "dérangée" qu'aux moments où elle le veut bien: Appels de fonctions callback, SendMessage() de Windows, etc.

Non : tu peux te faire descheduler à n'importe quel moment, et c'est hors de tout contrôle sur un OS à multitâche préemptif...
Il n'y a qu'en MT coopératif que tu peux (presque) garantir les emplacements de changement de contexte.

Il n'en reste pas moins vrai que les ISR existent sur ton OS, et que tu n'as PAS le contrôle dessus : en conséquence, ton code peut toujours être interrompu par un ISR, et rien ne te garantit qu'il n'utilise pas la "mauvaise" fonction... C'est pour ça que je parle de fonctions résistantes au MT "courant", mais qui peuvent parfaitement ne pas être intrinsèquement thread-safe.