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 !)
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 , dans le message
<alpine.LNX.2.00.1210181534250.3060@coulomb.univ-paris12.fr>, a écrit :
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.
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 18 octobre 2012, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
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
Le 18 octobre 2012, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LNX.2.00.1210181534250.3060@coulomb.univ-paris12.fr>, a écrit :
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).
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).
Le Fri, 19 Oct 2012 10:08:32 +0200, Lucas Levrel écrivait :
Le 18 octobre 2012, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
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
Le Fri, 19 Oct 2012 10:08:32 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 18 octobre 2012, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LNX.2.00.1210181534250.3060@coulomb.univ-paris12.fr>, a écrit :
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
Le Fri, 19 Oct 2012 10:08:32 +0200, Lucas Levrel écrivait :
Le 18 octobre 2012, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
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 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
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
Le Fri, 19 Oct 2012 11:45:58 +0200, Lucas Levrel écrivait :
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
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/
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/
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 Fri, 19 Oct 2012 12:21:18 +0200, Tonton Th écrivait :
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
Le Fri, 19 Oct 2012 12:21:18 +0200,
Tonton Th <tth@la.bas.invalid> écrivait :
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
Le Fri, 19 Oct 2012 12:21:18 +0200, Tonton Th écrivait :
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
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/
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/
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/
