Discussion :

[3DArchi]

Bonjour,
Peut-on dire les choses suivantes dans le cadre de la programmation par contrat :
-> Une fonction ré entrante : les invariants sont préservés pendant toute la durée de la fonction.
-> Une fonction Thread-safety : les invariants peuvent être rompus au sein d'une section protégée (mutex/section critique, etc.).

On sent un certain flottement dans la définition de réentrance vis à vis de thread-safety. Aussi, je me demandais si cette approche ne permet pas de bien comprendre la différence.

Ai-je tout faux ?

[3DArchi]

Bon, je crois que j'ai faux
La réentrance est en général définie comme la possibilité d'appeler une même fonction avec des paramètres différents. Donc, je peux très bien casser quelques invariants de mon objet courant pendant l'exécution de cette fonction sur celui-ci et appeler la fonction sur un autre objet. Cela va plus être lié aux éventuels variables statiques de la classe (ou variables globales).
A l'inverse une fonction thread-safe doit pouvoir être appelée par plusieurs threads sur le même objet. J'ai donc pas trop intérêt à casser les invariants...

A votre avis, comment s'articulent les invariants avec la réentrance et le thread-safety ?

[Médinoc]

Si tu comprends l'anglais, ceci peut te donner à réfléchir:
http://blogs.msdn.com/oldnewthing/ar...29/168719.aspx

Le problème, c'est que dès qu'on se met à parler d'autres choses que des variables globales/statiques, la notion devient floue : Une fonction agissant sur deux objets pourrait être dite thread-safe sur un des objets et pas l'autre!

[3DArchi]

Merci pour le lien. J'étais déjà tombé dessus. Et sur bien d'autres. Ce qui m'a justement amené à penser que cette notion de réentrance (à l'origine venant du monde de la programmation système et applicable dans le cadre des interruptions) avait du mal à être consensuellement définie dans le cadre de la programmation concurrente. A la limite, thread-safe parait plus facile à définir : grossièrement thread-safe = pas de race conditions -> utilisation de verrous si nécessaire.

[Luc Hermitte]

"reentrant" marche bien dans le cadre de la prog concurrente : il n'y a pas d'effet de bord visible (ou plutôt de type aberrant/tombe en marche) sur le résultat de la fonction à cause d'exécutions parallèles de celle-ci.

Dès que tu as un état partagé (var globale/statique, ou membre) qui peut évoluer et influencer le résultat pour produire des sorties indésirables, ce n'est pas réentrant.
J'ai tendance à considérer, à tord peut-être, qu'une fonction qui trace son nombre max d'exécutions parallèles comme "réentrante" si elle est justement capable de sortir ce nombre max.

EDIT: Hum ... on retrouve la notion de MT-safe -- BTW, plutôt que les locks les TSS/TLS marchent bien aussi.

[3DArchi]

"reentrant" marche bien dans le cadre de la prog concurrente : il n'y a pas d'effet de bord visible (ou plutôt de type aberrant/tombe en marche) sur le résultat de la fonction à cause d'exécutions parallèles de celle-ci.

Cette définition est un peu forte par rapport à ce qu'on trouve dans la littérature. "Pas d'effet de bord sur le résultat si exécution //" -> Il suffirait alors de protéger l'accès aux variables globales pour qu'une fonction soit réentrante. On trouve plutôt une distinction :
-> réentrant = peut être appelée concurremment avec des jeu de données différents (donc pas d'état partagé) + peut avoir des appels imbriqués dans une même tâche
-> thread-safe = peut être appelée concurremment avec un jeu de données identique + la garantie n'est assurée à priori que sur des tâches différentes

Dès que tu as un état partagé (var globale/statique, ou membre) qui peut évoluer et influencer le résultat pour produire des sorties indésirables, ce n'est pas réentrant.

C'est souvent présenté comme 'une fonction réentrante ne dépend que des paramètres qu'elle prend en entrée et ne retourne en sortie rien d'interne/globale. Une fonction réentrante est une fonction 'sans mémoire'.

J'ai tendance à considérer, à tord peut-être, qu'une fonction qui trace son nombre max d'exécutions parallèles comme "réentrante" si elle est justement capable de sortir ce nombre max.

EDIT: Hum ... on retrouve la notion de MT-safe -- BTW, plutôt que les locks les TSS/TLS marchent bien aussi.

Google + TSS = "Tout Sauf Sarkosy"
Google + TLS = "Transport Layer Security"
J'imagine que ce n'est pas tout à fait de ce sens dont tu parles...
Entres parenthèses, lock : facilité de langage car partagé par tous ceux qui font du multi-thread (MT).