Discussion :

[jamin]

Bonjour,

Je me pose des questions concernant l'utilisation des méthodes statiques dans un contexte multithread.

La définition du mot clé REENTRANT dans le préprocesseur garantit que ces méthodes seront thread-safes.

N'est-ce valable qu'avec gcc ? J'utilise en fait VisualStudio2008, et je n'ai pas trouvé l'équivalent !

[ram-0000]

Je n'en connais pas non plus (à part la relecture de code).

Pour être réentrante, une fonction statique ne doit pas modifier de variables globale et/ou statiques ou alors cette variable doit être protégée par une section critique.

D'ailleurs, je me demande si fonction réentrante et fonction thread-safe sont bien équivalents ou bien s'il y a des nuances subtiles.

[Lavock]

Je ne connais pas ce mot clef, mais une fonction réentrante, c'est plus que thread safe. Une fonction récursive par exemple et réentrante... Il ne peut pas y avoir de lock/mutex dans une fonction réentrante. Elle peut donc aussi être appelé par une ISR. Enfin, sous mesure que je me plante pas >< !

[jamin]

Donc si j'ai une méthode statique bien écrite :

Code :

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

1
2
3
4
5
static void MaFonctionStatique( ... mes parametres ... )
{
  // j'utilise 'mes parametres';
  // ...
}

qu'il y ait ou non une compilation REENTRANT n'a pas d'incidence.

Par contre si j'utilise une ressource partagée, il doit quand même moyen de se passer des mutex ! C'est une histoire de compilo, non ? Je vais regarder du côté d'Intel.

Code :

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

1
2
3
4
5
6
static maVariablePartagee;
static void MaFonctionStatique()
{
  // j'utilise 'maVariablePartagee';
  // ...
}

[3DArchi]

Salut,

Par contre si j'utilise une ressource partagée, il doit quand même moyen de se passer des mutex ! C'est une histoire de compilo, non ? Je vais regarder du côté d'Intel.

Pas à l'heure actuelle. La notion d'atomicité n'existe pas encore en C++ donc tout accès concurrent à une ressource est susceptible de provoquer une race condition.
Ensuite, cela dépend beaucoup de ton problème. Si tous les threads ne font que des accès en lecture, ben effectivement pas besoin de mutex. etc...
réentrance et thread safe ont souvent tendance à être interprétées différemment par chacun. Je te donne mon point de vue :

Dans le cadre de la programmation concurrente, une fonction réentrante est une fonction qui peut être exécutée correctement par plusieurs threads en même temps ou par le même thread avec des paramètres différents.

Une fonction est thread-safe si elle peut être appelée correctement par plusieurs threads distincts en même temps avec les mêmes paramètres.

[Lavock]

Par contre si j'utilise une ressource partagée, il doit quand même moyen de se passer des mutex ! C'est une histoire de compilo, non ? Je vais regarder du côté d'Intel.

Comme dit précemment, on ne peut faire apelle au mutex. Sinon, lorsque le même thread re-rentre dans la fonction, tu fais comment ?

Mais as-tu vraiment besoin d'une fonction réentrante ? Le thread-safe ne suffit pas ?

[3DArchi]

Comme dit précemment, on ne peut faire apelle au mutex. Sinon, lorsque le même thread re-rentre dans la fonction, tu fais comment ?

Si on prend la définition de réentrant comme une fonction qui peut être exécutée correctement par plusieurs threads en même temps ou par le même thread avec des paramètres différents ; alors les mutex ne servent à rien.

[Médinoc]

Attention, à ma connaissance une fonction peut être réentrante sans être thread-safe, et inversement.

[Mac LAK]

J'ai une définition différente à ce sujet...

Réentrance : propriété d'une fonction de pouvoir être interrompue par elle-même, notamment de pouvoir s'auto-appeler.
En d'autres mots, la fonction n'a pas de contexte implicite (elle peut bien sûr avoir un contexte explicite, passé en argument).

Thread-safe : propriété d'une fonction à pouvoir être exécutée en parallèle et de façon simultanée.
En d'autres mots, la fonction n'a pas d'effets de bord sur son contexte... Ceci implique donc qu'elle n'a pas de contexte implicite, donc qu'elle est réentrante.

Par contre, ne fonction réentrante n'est pas forcément thread-safe...

Le moyen le plus simple (mais pas le plus efficace !!) d'assurer les deux conditions est d'utiliser un mutex propre à la fonction, qui encadre son exécution complète.
Un moyen plus complexe (mais habituellement le plus performant) est de rajouter - si ce n'est pas déjà fait - un paramètre de contexte à la fonction, et de s'assurer de l'atomicité des opérations sur ledit contexte, notamment et surtout celles provoquant un effet de bord.

[zul]

La communauté (enfin wikipedia) n'est manifestement pas d'accord avec toi. Réentrant semble assimilié à pure (au sens fonctionnel) de la chose, et on a clairement Réentrance est plus fort que Thread-safe

[Médinoc]

Donc, une fonction ayant un contexte implicite empilable n'est pas réentrante, bien qu'elle puisse être interrompue par elle-même (par exemple, en appelant une fonction callback dans une boucle) ?

[Mac LAK]

D'un autre côté, même si Wikipédia a souvent raison, ce n'est pas toujours le cas... Et cela dépend aussi du point de vue de l'auteur : sur cet article, par exemple, le fond a été sur "programme" au lieu de "fonction" pendant un bail, il suffit de regarder l'historique... La page de discussion associée (EN) montre également une assez grosse polémique à ce sujet.
Donc, article sujet à caution.


On reprends :
Une fonction peut être réentrante sans être thread-safe : il faut et il suffit qu'elle aie un effet de bord sur un élément global/partagé qu'elle ne sait pas être global/partagé (=> donc, c'est un problème au niveau de l'appel, donc du ressort de l'utilisateur de la fonction)...

De plus, le concept de réentrance n'est PAS forcément lié au multitâche. Exemple ? Les fonctions récursives... Pour ma part, j'ai entendu parler de réentrance bien avant d'entendre parler de thread-safety, et sur des systèmes non-multitâches. Tout comme j'ai vu des API indiquer la réentrance des fonctions, et ô surprise : certaines fonctions réentrantes n'étaient pas thread-safe, notamment lorsqu'on les appelle avec les mêmes paramètres...

Passes donc un flux comme paramètre d'une fonction, et appelles-là en concurrence, tu risques de rigoler trente secondes...
Typiquement, fprintf est une fonction réentrante (elle prends en paramètre explicites toutes ses données), mais n'est pas thread-safe (utilise le même flux dans deux threads différents pour t'en convaincre).

Une fonction thread-safe, par contre, prends l'assurance que tout élément potentiellement problématique sera utilisé de façon atomique.


A noter qu'apparemment, 3DArchi et moi avons à peu de choses près la même définition, bien qu'il se base plus sur les paramètres passés à la fonction tandis que je le vois comme une propriété intrinsèque de la fonction... Il n'empêche que l'on classifierait les mêmes fonctions comme "réentrantes" ou "thread-safe", et que l'on a tous les deux la notion "thread-safety > réentrance".

[Mac LAK]

Donc, une fonction ayant un contexte implicite empilable n'est pas réentrante, bien qu'elle puisse être interrompue par elle-même (par exemple, en appelant une fonction callback dans une boucle) ?

Qu'appelles-tu "empilable", exactement ? Je doute que ce soit "élément mis sur la pile lors de l'appel"...

[Médinoc]

Je pense que ces deux notions, sans pour autant être orthogonales, ne sont pas sur une même ligne non plus.

De plus, tout cela est, comme tu l'as dit, lié au données: Une fonction peut gérer certains de ses paramètres de manière thread-safe et d'autres pas...

[Médinoc]

Qu'appelles-tu "empilable", exactement ? Je doute que ce soit "élément mis sur la pile lors de l'appel"...

Typiquement, mis sur UNE pile. Qui peut, dans certains cas, être la pile d'appel. Voici un exemple bidon:

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
__declspec(thread) int g_uneVariableGlobale; /*Variable en Thread-Local Storage (TLS)*/
 
typedef void (*PTRFONC)(intptr_t, float);
 
void FonctionQuiAppelleCallback(PTRFONC fncallback, size_t iterations, float increment, intptr_t user)
{
	int sauvegarde = g_uneVariableGlobale;
	g_uneVariableGlobale++;
	{
		float val = 0.0;
		size_t i;
		for(i=0 ; i<iteration ; i++, val+=increment)
		{
			fncallback(user, val);
		}
	}
	g_uneVariableGlobale=sauvegarde;
}

Bien sûr, on pourrait sûrement réécrire ça pour ne pas utiliser de variable globale du tout (en supposant qu'on ne dépende pas d'une bibliothèque à l'interface mauvaise, etc.). Mais dans le cas actuel, peut-on dire que la fonction est réentrante ou non?

[Mac LAK]

Mais dans le cas actuel, peut-on dire que la fonction est réentrante ou non?

Je dirais que non : elle utilise une variable globale qui n'est pas passée en paramètre, et tu ne peux pas garantir l'absence de conflit sur cette globale de façon systématique.
De plus, il manque également en paramètre le contexte de la callback, qui fait partie du contexte de la fonction.

[Médinoc]

Euh, si, le contexte de la callback, je l'ai mis!


Quant à la variable globale, je pourrais aussi bien l'avoir mise en static dans la fonction (généralement quand je fais ça, j'utilise du Thread-Local Storage (TLS) de manière explicite).

En fait, j'ai déjà utilisé un code de ce genre pour pouvoir passer un contexte à une callback de qsort().

[Lavock]

Une fonction thread-safe, par contre, prends l'assurance que tout élément potentiellement problématique sera utilisé de façon atomique.

C'est là où ça cloche, le lock/mutex dans du réentrant... C'est un peu absurde. C'est simplement deux choses différentes...

Néanmoins, je suis globalement d'accord avec tes différentes définitions, à cela que le réentrant ne peux avoir de ressource protégé, et par conséquent, être appelé par une isr...

[Mac LAK]

Euh, si, le contexte de la callback, je l'ai mis!

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.

Quant à la variable globale, je pourrais aussi bien l'avoir mise en static dans la fonction (généralement quand je fais ça, j'utilise du Thread-Local Storage (TLS) de manière explicite).

Sauf qu'avec un TLS, et ses propriétés intrinsèques, tu garantis le thread-safe vis-à-vis de cette variable. Par contre, tu ne garantis pas qu'une récursion au sein du même thread sera possible, tout dépend de ce qu'est cette variable et de comment elle est utilisée.
Typiquement, si tu stocke un handle de fichier dans ce TLS, tu aboutis aux mêmes problèmes qu'avec les flux : une utilisation conjointe et/ou récursive provoquera des problèmes... Pourtant, vis-à-vis d'un AUTRE thread, tu as bien une isolation "parfaite" et la garantie qu'un seul et unique thread peut y accéder.

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, et ce n'est pas forcément vrai. Dans 99% des cas, ce sera bien le cas, donc la fonction sera thread-safe. Mais tu as toujours une possibilité que ça crashe, en fonction du compilateur et/ou des options d'optimisation.

C'est pour ça que je dis qu'elle n'est pas réentrante, du moins dans un cadre général, et donc qu'elle n'est pas thread-safe.

Après, je n'ai aucun doute sur le fait qu'il existe des cas d'utilisation où les problèmes intrinsèques de la fonction ne se déclencheront pas : je fais assez souvent ce genre de choses (optimisation très bas niveau) pour savoir que, dans certains cas très strictement contrôlés, on peut faire sauter pas mal de protections qui seraient normalement nécessaires... Et ceci sans provoquer de bugs, bien sûr.

[Mac LAK]

C'est là où ça cloche, le lock/mutex dans du réentrant... C'est un peu absurde. C'est simplement deux choses différentes...

C'est bien pour ça que je classe la réentrance comme "en dessous" de thread-safe, qui requiert plus d'opérations / contrôles que la réentrance "simple"...

Cependant, ça ne veut pas dire qu'une fonction réentrante ne peut pas posséder / utiliser d'objets de synchronisation... Notamment parce que tu peux parfaitement les lui passer en paramètre !

Simplement, elle ne doit pas en utiliser définis de façon globale. Éventuellement, on peut faire une petite entorse avec un mutex LOCAL à la fonction et défini comme static, car dans ce cas il n'est effectivement pas utilisable en dehors de la fonction elle-même (et il est pourtant "global" la plupart du temps). Mais il ne faut alors bien sûr jamais le passer à une sous-fonction.