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 !)
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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Olivier Miakinen
Le 19/10/2012 12:09, JKB a écrit :
Personnellement, j'utilise :
gettimeofday(&horodatage, NULL);
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés pour que tous les bits de tv_usec ne soient pas modifiés, il suffit que les bits effectivement modifiés soient masqués par des bits à 1 dans tv_sec pour que deux valeurs successives soient absolument identiques (voire que de nombreuses valeurs successives le soient).
Cordialement, -- Olivier Miakinen
Le 19/10/2012 12:09, JKB a écrit :
Personnellement, j'utilise :
gettimeofday(&horodatage, NULL);
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un
peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés
pour que tous les bits de tv_usec ne soient pas modifiés, il suffit
que les bits effectivement modifiés soient masqués par des bits à 1
dans tv_sec pour que deux valeurs successives soient absolument
identiques (voire que de nombreuses valeurs successives le soient).
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés pour que tous les bits de tv_usec ne soient pas modifiés, il suffit que les bits effectivement modifiés soient masqués par des bits à 1 dans tv_sec pour que deux valeurs successives soient absolument identiques (voire que de nombreuses valeurs successives le soient).
Cordialement, -- Olivier Miakinen
JKB
Le 20 Oct 2012 15:25:29 GMT, Bruno Ducrot écrivait :
On 19-10-2012, JKB wrote:
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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes correctement, je ne vois pas trop le problème...
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 20 Oct 2012 15:25:29 GMT,
Bruno Ducrot <ducrot@echo.fr> écrivait :
On 19-10-2012, JKB wrote:
Le Fri, 19 Oct 2012 11:45:58 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> é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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur
certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes
correctement, je ne vois pas trop le problème...
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 20 Oct 2012 15:25:29 GMT, Bruno Ducrot écrivait :
On 19-10-2012, JKB wrote:
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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes correctement, je ne vois pas trop le problème...
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
JKB
Le Sat, 20 Oct 2012 23:23:38 +0200, Olivier Miakinen <om+ écrivait :
Le 19/10/2012 12:09, JKB a écrit :
Personnellement, j'utilise :
gettimeofday(&horodatage, NULL);
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés pour que tous les bits de tv_usec ne soient pas modifiés, il suffit que les bits effectivement modifiés soient masqués par des bits à 1 dans tv_sec pour que deux valeurs successives soient absolument identiques (voire que de nombreuses valeurs successives le soient).
Pas bête. Je note.
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 Sat, 20 Oct 2012 23:23:38 +0200,
Olivier Miakinen <om+news@miakinen.net> écrivait :
Le 19/10/2012 12:09, JKB a écrit :
Personnellement, j'utilise :
gettimeofday(&horodatage, NULL);
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un
peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés
pour que tous les bits de tv_usec ne soient pas modifiés, il suffit
que les bits effectivement modifiés soient masqués par des bits à 1
dans tv_sec pour que deux valeurs successives soient absolument
identiques (voire que de nombreuses valeurs successives le soient).
Pas bête. Je note.
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 Sat, 20 Oct 2012 23:23:38 +0200, Olivier Miakinen <om+ écrivait :
Le 19/10/2012 12:09, JKB a écrit :
Personnellement, j'utilise :
gettimeofday(&horodatage, NULL);
puis (horodatage.tv_usec | horodatage.tv_sec) comme graine [...]
Je pense que (horodatage.tv_usec ^ horodatage.tv_sec) devrait être un peu plus sûr. En effet, si tu fais des appels suffisamment rapprochés pour que tous les bits de tv_usec ne soient pas modifiés, il suffit que les bits effectivement modifiés soient masqués par des bits à 1 dans tv_sec pour que deux valeurs successives soient absolument identiques (voire que de nombreuses valeurs successives le soient).
Pas bête. Je note.
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
Bruno Ducrot
On 21-10-2012, JKB wrote:
Le 20 Oct 2012 15:25:29 GMT, Bruno Ducrot écrivait :
On 19-10-2012, JKB wrote:
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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes correctement, je ne vois pas trop le problème...
Je me méfie d'un type opaque pour lequel il est nécessaire d'avoir un pthread_equal(). Et quand bien même, je vois trop souvent de mauvais casts de pthread_t, à commencer par la page wikipedia :
http://en.wikipedia.org/wiki/POSIX_Threads
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 21-10-2012, JKB wrote:
Le 20 Oct 2012 15:25:29 GMT,
Bruno Ducrot <ducrot@echo.fr> écrivait :
On 19-10-2012, JKB wrote:
Le Fri, 19 Oct 2012 11:45:58 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> é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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur
certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes
correctement, je ne vois pas trop le problème...
Je me méfie d'un type opaque pour lequel il est nécessaire d'avoir un
pthread_equal(). Et quand bien même, je vois trop souvent de mauvais
casts de pthread_t, à commencer par la page wikipedia :
Le 20 Oct 2012 15:25:29 GMT, Bruno Ducrot écrivait :
On 19-10-2012, JKB wrote:
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.
Certains rajoutent le tid pour une graîne, ce qui peut être très rigolo sur certains OS. Je constate avec plaisir que tu ne commet pas cette erreur.
Pourquoi ? Si tu sais ce qu'est le TID, que tu le castes correctement, je ne vois pas trop le problème...
Je me méfie d'un type opaque pour lequel il est nécessaire d'avoir un pthread_equal(). Et quand bien même, je vois trop souvent de mauvais casts de pthread_t, à commencer par la page wikipedia :
