java.util.Random.nextInt() thread safety

Discussion in 'Java' started by Sakagami Hiroki, Aug 29, 2006.

  1. 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
    Sakagami Hiroki, Aug 29, 2006
    #1
    1. Advertising

  2. 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.

    Patricia
    Patricia Shanahan, Aug 29, 2006
    #2
    1. Advertising

  3. Sakagami Hiroki

    hiwa Guest

    Patricia Shanahan ã®ãƒ¡ãƒƒã‚»ãƒ¼ã‚¸:

    > 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.
    >
    > Patricia

    And, these code also would help:
    http://www.javaconcurrencyinpractice.com/listings.html
    (listing 15.4 and 15.5)
    BTW, their book suggests that using ThreadLocal for thread specific
    random number sequence achieves much higher performance than using
    shared thread-safe sequence.
    hiwa, Aug 29, 2006
    #3
  4. Sakagami Hiroki

    Eric Sosman Guest

    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, Aug 29, 2006
    #4
  5. Eric Sosman wrote:
    >
    > 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()?


    How did you find out from the documentation that next() is thread safe?

    The sample implementation in the JDK 1.5.0 documentation is not,
    although the code is.

    In any case, even if Random were final I would not know, without looking
    at the nextInt() source code, that it does not use or modify any
    variables. I already know from looking at next() that sample
    implementations in the javadocs are abstractions that do not necessarily
    match the thread safety of the real code.

    >
    > 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.
    >


    Anything the Javadoc says about a non-final method in a non-final class,
    that is not forced by the declaration, can be broken by a subclass.

    For example, one could override nextInt(int) always return 42,
    regardless of the state of the seed or the value of the int parameter.
    Does that make it inappropriate for the Javadoc to say "Returns a
    pseudorandom, uniformly distributed int value between 0 (inclusive) and
    the specified value (exclusive),..."?

    I would view a Javadoc thread safety statement exactly the same way I
    view a range limit within type, or a statement about postconditions in
    general, as a contract that the Sun-supplied implementation does follow,
    and that a subclass should follow.

    Patricia
    Patricia Shanahan, Aug 29, 2006
    #5
  6. Sakagami Hiroki

    Eric Sosman Guest

    Patricia Shanahan wrote On 08/29/06 13:03,:
    > Eric Sosman wrote:
    >
    >>Patricia Shanahan wrote On 08/28/06 23:19,:
    >>>
    >>>Time for one of my standard rants.
    >>>[Sun documents thread-safety in Java inadequately]

    >>
    >> 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.

    >
    > How did you find out from the documentation that next() is thread safe?
    >
    > The sample implementation in the JDK 1.5.0 documentation is not,
    > although the code is.


    The sample implementation in the Javadoc synchronizes
    on the Random instance before accessing the mutable state
    (the `seed' element). Perhaps I'm too trusting, but I took
    that to mean that synchronization was part of the "contract"
    of next(), even if the actual implementation provides for it
    in a different way.

    Of course, the existence of one synchronized method is not
    enough, by itself. There *could* always be some other method
    that swizzles `seed' without synchronizing; locking the front
    door while leaving the back door ajar keeps out no burglars.
    But there's no reason to use `synchronized' any place at all
    unless you're going to use it every place that matters, so I
    understood its presence in the sample implementation as meaning
    that it *would* be used wherever necessary, and that therefore
    next() was thread-safe.

    Yes, I'm reading more into the Javadoc than is explicitly
    stated -- get me on the witness stand with Perry Mason cross-
    examining, and I'll be in deep trouble in no time at all! But
    practically all the computer documentation I've seen requires
    the reader to make some inferences and fill in some gaps; I
    don't think its implausible to conclude from the Javadoc that
    next() is thread-safe.

    > [...]
    > I would view a Javadoc thread safety statement exactly the same way I
    > view a range limit within type, or a statement about postconditions in
    > general, as a contract that the Sun-supplied implementation does follow,
    > and that a subclass should follow.


    I'd be interested in your ideas about how such statements
    could be formalized into something the javadoc processor -- or
    even javac! -- could do something useful with. Annotations
    seem the obvious place to start, but how do we annotate these
    notions? You referred earlier to Sun's use of standardized
    terms like "MT-Safe" in non-Java documentation, but I think it
    might be tricky to transfer such terms to Java.

    --
    Eric Sosman, Aug 29, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Elmar Baumann
    Replies:
    0
    Views:
    596
    Elmar Baumann
    Feb 2, 2004
  2. Mike Brown

    random number generator thread safety

    Mike Brown, Nov 8, 2005, in forum: Python
    Replies:
    3
    Views:
    389
    Raymond Hettinger
    Nov 9, 2005
  3. Mark
    Replies:
    0
    Views:
    2,816
  4. Replies:
    2
    Views:
    520
    Roedy Green
    Jan 4, 2008
  5. briteguy
    Replies:
    10
    Views:
    5,627
    John B. Matthews
    Mar 18, 2009
Loading...

Share This Page