Mail Archives: djgpp/1998/03/29/15:02:29
From: | "John M. Aldrich" <fighteer AT cs DOT com>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Re: Srandom()
|
Date: | Sun, 29 Mar 1998 12:59:29 -0500
|
Organization: | Two pounds of chaos and a pinch of salt.
|
Lines: | 26
|
Message-ID: | <351E8C01.69BF@cs.com>
|
References: | <6fku51$909 AT freenet-news DOT carleton DOT ca>
|
NNTP-Posting-Host: | ppp217.cs.com
|
Mime-Version: | 1.0
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Paul Derbyshire wrote:
>
> How quickly does srandom() in DJGPP's libc execute? Would an added
> srandom() before every random() in a program that uses random()
> extensively cause a noticeable slowdown? Reason I ask is because something
> like that might be necessary to make a threadsafe random number generator
> class so that each random number generator instance can be seeded
> independently and give consistent results.
I think I understand what you're saying. However, calling srandom()
before each call to random() is a nearly foolproof way to _not_ generate
a random sequence of numbers. It's been a while since I've worked on a
multithreaded program, but one possibility would be to reseed each
parent process immediately after the call to fork(), using the returned
PID as the seed, or, for better results, the PID multiplied by random(),
or something similar.
Please note that these are just suggestions. YMMV. :-)
--
---------------------------------------------------------------------
| John M. Aldrich | "A woman is not property, and hus- |
| aka Fighteer I | bands who think otherwise are living |
| mailto:fighteer AT cs DOT com | in a dreamworld." |
| http://www.cs.com/fighteer | - Lazarus Long |
---------------------------------------------------------------------
- Raw text -