fopen, fread et threads

Le
Lucas Levrel
Bonjour,

J'utilise un générateur de nombres pseudo-aléatoires (dans une classe C++)
qui s'initialise à partir de /dev/urandom, comme ceci :

FILE* urandom = fopen( "/dev/urandom", "rb" );
if( urandom )
{

success = fread( s, sizeof(uint32), 1, urandom );

fclose(urandom);
}

Si maintenant je crée plusieurs threads qui possèdent chacun une instance
du générateur, et qui vont donc chacun faire l'initialisation ci-dessus,
dois-je emballer tout ça dans un mutex, ou peuvent-ils simultanément
ouvrir et lire dans urandom ? (À moins que fopen/fclose fonctionnent
comme un mutex, on peut toujours rêver !)

Merci.

--
LL
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #24881902
Lucas Levrel , dans le message
Si maintenant je crée plusieurs threads qui possèdent chacun une instance
du générateur, et qui vont donc chacun faire l'initialisation ci-dessus,
dois-je emballer tout ça dans un mutex, ou peuvent-ils simultanément
ouvrir et lire dans urandom ?



Je suppose que tu poses la question pour le device lui-même, et que tu as
bien pris soin que toutes les variables utilisées par le code soient
locales, et que tu sais que les fonctions de stdio sont thread-safe.

La réponse pour /dev/urandom est que bien sûr plusieurs processus ou threads
peuvent le lire en même temps, ce serait problématique sinon.

Mais pourquoi me croire sur parole quand il est si facile de tester ? Tu
remplaces ta lecture de 4 octets par une lecture de 40 Mo, tu lances deux
threads et tu vois ce qui se passe.
Lucas Levrel
Le #24883412
Le 18 octobre 2012, Nicolas George a écrit :

Lucas Levrel , dans le message
Si maintenant je crée plusieurs threads qui possèdent chacun une instance
du générateur, et qui vont donc chacun faire l'initialisation ci-dessus,
dois-je emballer tout ça dans un mutex, ou peuvent-ils simultanément
ouvrir et lire dans urandom ?



Je suppose que tu poses la question pour le device lui-même,



Oui.

La réponse pour /dev/urandom est que bien sûr plusieurs processus ou threads
peuvent le lire en même temps, ce serait problématique sinon.



OK. Vont-ils bien lire des choses différentes ?

Mais pourquoi me croire sur parole quand il est si facile de tester ? Tu
remplaces ta lecture de 4 octets par une lecture de 40 Mo, tu lances
deux threads et tu vois ce qui se passe.



Puisque de manière générale, s'assurer du bon fonctionnement d'un
programme multi-thread par un test est une très mauvaise idée, je n'ai pas
ce réflexe. Évidemment avec 40 Mo, ça limite les risques de « tomber en
marche » (encore que je n'aie aucune idée du débit de lecture dans
urandom).

--
LL
Lucas Levrel
Le #24883402
Le 18 octobre 2012, Nicolas George a écrit :


J'oubliais : merci pour ta réponse.

--
LL
JKB
Le #24883392
Le Fri, 19 Oct 2012 10:08:32 +0200,
Lucas Levrel
Le 18 octobre 2012, Nicolas George a écrit :

Lucas Levrel , dans le message
Si maintenant je crée plusieurs threads qui possèdent chacun une instance
du générateur, et qui vont donc chacun faire l'initialisation ci-dessus,
dois-je emballer tout ça dans un mutex, ou peuvent-ils simultanément
ouvrir et lire dans urandom ?



Je suppose que tu poses la question pour le device lui-même,



Oui.

La réponse pour /dev/urandom est que bien sûr plusieurs processus ou threads
peuvent le lire en même temps, ce serait problématique sinon.



OK. Vont-ils bien lire des choses différentes ?

Mais pourquoi me croire sur parole quand il est si facile de tester ? Tu
remplaces ta lecture de 4 octets par une lecture de 40 Mo, tu lances
deux threads et tu vois ce qui se passe.



Puisque de manière générale, s'assurer du bon fonctionnement d'un
programme multi-thread par un test est une très mauvaise idée, je n'ai pas
ce réflexe. Évidemment avec 40 Mo, ça limite les risques de « tomber en
marche » (encore que je n'aie aucune idée du débit de lecture dans
urandom).



Mouais, ça reste une très mauvaise idée pour s'assurer du bon
fonctionnement d'un programme multithreadé. Et d'un autre côté, tu
ne maîtrises pas a priori la qualité de urandom.

Personnellement, j'utilise une instance de ranlux par thread
initialisé par le timer à haute résolution de la machine (avec un
test pour être sûr que les racines sont bien différentes).

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Lucas Levrel
Le #24883382
Le 19 octobre 2012, JKB a écrit :

Personnellement, j'utilise une instance de ranlux par thread
initialisé par le timer à haute résolution de la machine



clock() ?

--
LL
JKB
Le #24883372
Le Fri, 19 Oct 2012 11:45:58 +0200,
Lucas Levrel
Le 19 octobre 2012, JKB a écrit :

Personnellement, j'utilise une instance de ranlux par thread
initialisé par le timer à haute résolution de la machine



clock() ?



Pourquoi pas ? Personnellement, j'utilise :

gettimeofday(&horodatage, NULL);

puis (horodatage.tv_usec | horodatage.tv_sec) comme graine (en
vérifiant l'unicité entre threads. Il y a donc un mutex qui traîne.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #24883362
On 10/19/2012 10:31 AM, JKB wrote:

Et d'un autre côté, tu
ne maîtrises pas a priori la qualité de urandom.



Euh, je pense quand même que ce truc a été testé, torturé,
audité et même trollé un nombre suffisant de fois pour être
relativement digne de confiance, sauf sur une machine qui
serait catatonique, non ?



--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
JKB
Le #24893082
Le Fri, 19 Oct 2012 12:21:18 +0200,
Tonton Th
On 10/19/2012 10:31 AM, JKB wrote:

Et d'un autre côté, tu
ne maîtrises pas a priori la qualité de urandom.



Euh, je pense quand même que ce truc a été testé, torturé,
audité et même trollé un nombre suffisant de fois pour être
relativement digne de confiance, sauf sur une machine qui
serait catatonique, non ?



La question est surtout de savoir à quoi correspond urandom sur un
système donné et surtout de connaître ses propriétés statistiques.
J'ai appris à ne pas faire d'hypothèses là-dessus.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #24893072
On 10/19/2012 12:49 PM, JKB wrote:

Euh, je pense quand même que ce truc a été testé, torturé,
audité et même trollé un nombre suffisant de fois pour être
relativement digne de confiance, sauf sur une machine qui
serait catatonique, non ?



La question est surtout de savoir à quoi correspond urandom sur un
système donné et surtout de connaître ses propriétés statistiques.
J'ai appris à ne pas faire d'hypothèses là-dessus.



Ah oui, milles excuses. C'est vrai que je suis bloqué sur ma
Bubuntu en ce moment, mais bon, les petits essais que j'ai
faits et ce que j'ai entrevu dans le Ternet me donnent assez
confiance. Par contre, en dehors du Linux, je ne sais pas que
dire. sauf que...

... J'ai sous la main une dizaine de Blade1500 que l'on peut
trasher à loisir. Elles sont toutes en OpenBSD bien frais, vu
qu'on les trashent régulièrement ;)

Si tu proposes un protocole de test de /dev/urandom qui soit
à la fois rigoureux et amusant à implémenter, je connais une
bande de na><ors à qui ça peut bien plaire.



--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Lucas Levrel
Le #24893062
Le 19 octobre 2012, JKB a écrit.


Merci pour les tuyaux.


--
LL
Publicité
Poster une réponse
Anonyme