Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Renseigne-toi sur les spécificités de Windows et des compilateurs prévus pour, avant de partir d'exemples incompatibles (POSIX).Envoyé par Moi-même
Et notamment, sur l'attribut __declspec(thread).
PS: À aucun moment je n'ai contesté que les données était faussées sous POSIX : Je dis seulement qu'elle ne le seront pas sous Windows, même si ce n'est pas explicitement documenté pour cette fonction-là : En règle générale, les fonctions non-réentrantes de Microsoft sont thread-safe.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
PS: À aucun moment je n'ai contesté que les données était faussées sous POSIX : Je dis seulement qu'elle ne le seront pas sous Windows, même si ce n'est pas explicitement documenté pour cette fonction-là : En règle générale, les fonctions non-réentrantes de Microsoft sont thread-safe.[/QUOTE]
Non, t'as dis "probablement" et "probable"
Et tu te restreint dorénavant à Windows, alors que le programme risque d'avoir des données faussées sous tout système. (Windows compris, jusqu'à preuve du contraire)
Encore une fois: je ne dis rien d'autres que les données peuvent être faussée d'un thread à l'autre. Rien de plus.
En effet, c'est très probable connaissant les habitudes de Microsoft.
Qu'il en soit autrement :
- Serait une incohérence par rapport au reste de la CRT (oui, j'ai dit "en règle générale") et serait considéré comme un bug,
- Rendrait les faits constatés exponentiellement improbables et exponentiellement difficiles à reproduire: Modifier la charge du système modifierait le comportement.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
"probablement" puis "ne le seront pas" et maintenant "très probable connaissant les habitudes de Microsoft"...
Alors que je ne fais que pointer du doigt les risques de l'utilisation multi-thread de rand().
(C'est pas un bon point pour ma confiance de Microsoft)
Ben oui.
Tout ce qui n'est pas explicitement documenté est probabiliste.
La probabilité d'un bug n'est pas nulle, non plus.
En effet, si variable partagée il y a, il reste une chance infime pour que par miracle, chaque appel à rand() ait été fait exactement simultanément, si bien que chaque thread récupère la valeur avant que l'autre l'incrémente, et ce pour toute la durée de la boucle, et quelle que soit la charge du système.
Mais alors, bonne chance pour reproduire ça...
PS: On sait qu'on ne peut logiquement pas utiliser rand() en multithread sans prendre en compte le système. Et là, le comportement observé lui-même dépendait du système et n'est pas reproductible (là encore, très très très improbable, évidemment) sur un système où la variable est partagée.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Bah au moins on doit être d'accord pour dire que POSIX est mieux documenté sur rand()... (C'est pas un bon point pour ma confiance de Microsoft)
Bah ça peut dépendre de la fréquence d'appel à la fonction rand(), et de son implémentation.
Si par exemple deux vecteurs sont initialisés en même temps, c'est peut-être pas négligeable, puisque la fonction rand() lit la variable statique, calcule une nouvelle valeur aléatoire et récrit la variable statique.
Mieux documenté pour son implémentation de rand().
Comme nous parlons de comportement multi-thread, tout est dépendant de l'implémentation.
PS: À quelle heure pars-tu déjeuner ? J'ai faim moi...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
J'ai fais exprès de restreindre à la doc sur rand(). J'ai pas envie de débattre sur les autres fonctions!
ok, on arrête là
Ça, c'est testable : Nous POUVONS décaler artificiellement pour s'assurer que les vecteurs ne soient pas initialisés en même temps.
Et là, si les séquences sont à nouveau identiques, nous aurons une preuve tangible que cela ne dépend pas d'une race condition.
Je testerai cela si j'ai le temps...
Edit: OK, à plus tard.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
C'est pas identiques mais faussées. Et même si c'était totalement différent ça prouverait rien du tout, les valeurs sont peut-être dépendantes. Et puis rand() est intrinsèquement lui-même faussé puisque je sais que rand() était jugé comme pas suffisamment pseudo-aléatoire par certains collègues qui avaient besoin de pas mal de données (ils avaient des artéfactes dans le programme, et ont utilisé une librairie mathématique plus précise).Et là, si les séquences sont à nouveau identiques, nous aurons une preuve tangible que cela ne dépend pas d'une race condition.
Si tu fais le test, fais le pour toi ou par curiosité, moi je m'en moque (j'utilise pas la fonction rand). Bon j'arrête.
DE RETOUR!
Mais mon cher, la question est justement sur le mot "identiques" : C'est ce qui m'a permis toutes ces suppositions sur l'implémentation probable de rand() chez Microsoft.
Si les valeurs n'avaient pas été identiques, jamais je ne me serais permis la suggestion de mon premier post...
Quoi qu'il en fût, plutôt que de faire un programme de test, je suis directement allé regarder dans le code source de la CRT Microsoft (ce code source est fourni avec Visual). Ce code stocke sa graine aléatoire dans :
Nous avons donc confirmation que l'implémentation Microsoft de rand() utilise du thread-local storage, et est donc thread-safe.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Naturellement, cela ne dit rien sur les autres implémentations.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je disais que srand n'était pas SUFFISANT pour assurer la validité des suites aléatoires de 2 threads et j'incitais à la prudence.
Si tu dis vrai pour le stockage de la "graine" sous Windows alors rand() est "très probablement" thread-safe pour Windows. Dommage qu'il faille s'en assurer dans les sources...
En effet, ce serait loin d'être suffisant sous POSIX. Mais ça l'est sous Windows avec la CRT de Microsoft.
Dommage en effet. Cela aurait dû être documenté. Je pense que ceux qui ont fait la doc ont oublié que rand() faisait partie des fonctions non-réentrantes au même titre que strtok()...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
[debutant]
Juste une queston hors sujet, qu'est-ce qu'une fonction réentrante?
J'ignore la "vraie" définition, mais ça veut plus ou moins dire que son résultat (effets de bord compris) sera le même si les paramètres (pour des pointeurs, valeurs pointées comprises) sont les mêmes. Et ce, indépendamment des appels précédents à cette fonction.
Ce qui n'est clairement pas le cas de rand(), puisque ces paramètres sont toujours void, et sa valeur de retour change tout le temps.
Ce n'est pas non plus le cas de strtok() si le premier paramètre est NULL : On aura beau sauvegarder la chaîne modifiable passée en paramètre et la restaurer, au prochain appel le résultat ne sera pas le même, car la fonction strtok() garde un pointeur en mémoire.
La fonction strtok_r() est une version réentrante de strtok(), car elle fait de ce pointeur un paramètre. Alors, le résultat de strtok_r() ne dépend plus que de ses paramètres, et en passant deux fois les mêmes paramètres (pas seulement les pointeurs, mais aussi les valeurs pointées), on obtient deux fois les mêmes résultats.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
La fonction POSIX rand_r() est réentrante pour la même raison : la graine courante est devenue un paramètre, et si tu passes deux fois la même graine, tu auras deux fois la même valeur et deux fois la même "nouvelle graine".
Réentrant signifie également qu'une fonction n'est pas génée par un appel récursif (c'est possible pour des fonctions qui prennent des pointeurs de fonction en paramètre, comme sort()).
D'une manière générale, "réentrant" c'est mieux que "thread-safe", mais ici "thread-safe" n'implique pas qu'on puisse accéder dans deux threads simultanés à la même variable : Ça indique généralement au contraire que les variables ne sont PAS partagées entre les threads.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
reentrante veut dire qu'une fonction peut avoir plusieurs executions en cours (3 grandes causes: les interruptions/exceptions, la recursivite, le multithread).
Ca c'est une fonction pure. Une fonction peut etre reentrante sans etre pure.
Merci pour vos réponses
rand() n'est pas une fonction réentrante.Pour faire simple j'ai un rand() dans la méthode Run qui sert à générer un int aléatoire pour appeler la méthode Sleep() et cependant mes 2 Threads qui s'executent en parallèle génèrent la même valeur.
Un petite explication ?
Sinon à part ça, c'est parfaitement normal. Un générateur de nombres pseudo-aléatoires est parfaitement déterministe. C'est sa 'seed' qui le rend aléatoire.
Répondre avec citation
Partager