Re: java.util.Random.nextInt() thread safety
Patricia Shanahan wrote On 08/28/06 23:19,:
Sakagami Hiroki wrote:
Hi,
Is java.util.Random.nextInt() thread safe? I can't find whether it is
or not in the javadoc API document.
I want to use it like this:
import java.util.Random;
public class Foo {
private static final Random rng = new Random();
private final int myID = rng.nextInt();
public int getMyID() {
return myID;
}
}
Regards,
--
Sakagami Hiroki
Time for one of my standard rants.
A long time ago, Sun noticed that programmers need to know the
multi-thread safety of functions they call, and devised a scheme
that is used throughout the Solaris documentation. The man page for each
Solaris system call or library function is required to directly state
the "MT-Level", in a fixed section of the man page.
Why, Why, WHY didn't Sun apply this sane, programmer-friendly scheme to
the Java documentation?
Indeed, I would like Javadoc to have a standard set of terms for the
multi-thread safety, and an option to warn if it is not stated.
Anyway, I've taken a look at the Random nextInt() code in 1.5. It uses
an AtomicLong for the seed, and does a compareAndSet to update it, so
all should be well.
(Disclaimer: I work for Sun, but I don't speak for Sun.)
The Javadoc shows that java.util.Random#nextInt() is just
a call on the next() method, and that java.util.Random#next()
is thread-safe. What can be inferred about the thread-safety
of nextInt()?
Not much, because when nextInt() calls next() it might not
be calling java.util.Random#next()! Random is a non-final
class that can be extended, and an extending class can override
the next() method -- indeed, that's probably the main reason to
extend Random (so you can plug in the Mersenne Twister, say,
instead of java.util.Random's less rigorous generator). Since
nextInt() "inherits" its thread-safety or lack thereof from the
next() implementation, and since the universe of implementations
is unknown ...
The Javadoc could probably be improved, but I don't see how
a formal thread-safety annotation could be made to work for a
non-final class. Perhaps a natural-language statement to the
effect that the methods of Random are thread-safe if used with
Random's own implementations would be helpful, but that's about
as far as I think one could go without creating a false sense
of security.
--
Eric.Sosman@sun.com