Is 'new' operator thread-safe?

Discussion in 'Java' started by xie bo, Dec 5, 2006.

  1. xie bo

    xie bo Guest

    Hi,

    Is 'new' operator thread-safe? Is there any reference (e.g., JSR) to
    say it?

    Why this question? C++ standard does not care thread or thread-safe,
    then 'new' operator thread-safty in C++ depends on implementation (e.g,
    MFC 2.0 is not thread safe for 'new' operator).

    Thanks!
    xie bo, Dec 5, 2006
    #1
    1. Advertising

  2. xie bo wrote:
    > Hi,
    >
    > Is 'new' operator thread-safe? Is there any reference (e.g., JSR) to
    > say it?
    >
    > Why this question? C++ standard does not care thread or thread-safe,
    > then 'new' operator thread-safty in C++ depends on implementation (e.g,
    > MFC 2.0 is not thread safe for 'new' operator).


    Are we talking about Java or C++? But anyhow:

    Yes, of course "new" keeps care about all precautions that must be taken
    care of when threads are used. You do not need to synchronize it
    yourself. (Would be pretty pointless if so). This is as far as Java is
    concerned.

    C++ is different, but mostly because there is nothing like a "thread"
    in the standard. An implementation might provide threads, and might
    decide to make the operator new thread-safe or not. In fact, I would
    expect any reasonable implementation of "operator new" in an
    implementation that supports POSIX threads to be thread-safe in this
    respect, and g++ is a reasonable implementation.

    So long,
    Thomas
    Thomas Richter, Dec 5, 2006
    #2
    1. Advertising

  3. xie bo

    Eric Sosman Guest

    xie bo wrote:
    > Hi,
    >
    > Is 'new' operator thread-safe? Is there any reference (e.g., JSR) to
    > say it?


    `new' itself is thread-safe. The constructors
    may or may not be; it depends on what they do.

    Reference? Oh, I dunno, but I'd be willing to
    bet you'll find something in the JLS.

    --
    Eric Sosman
    lid
    Eric Sosman, Dec 5, 2006
    #3
  4. xie bo

    xie bo Guest

    > Reference? Oh, I dunno, but I'd be willing to
    > bet you'll find something in the JLS.


    I checked JLS and following is citation.
    -------
    Section 17.5 Final Field Semantics
    ....
    An object is considered to be completely initialized when its
    constructor finishes. A thread that can only see a reference to an
    object after that object has been completely initialized is guaranteed
    to see the correctly initialized values for that object's final fields.
    -------

    Is the above reference mean '"new" operator is thread-safe for Java'?

    Thanks!
    xie bo, Dec 5, 2006
    #4
  5. xie bo

    Oliver Wong Guest

    "xie bo" <> wrote in message
    news:...
    >> Reference? Oh, I dunno, but I'd be willing to
    >> bet you'll find something in the JLS.

    >
    > I checked JLS and following is citation.
    > -------
    > Section 17.5 Final Field Semantics
    > ...
    > An object is considered to be completely initialized when its
    > constructor finishes. A thread that can only see a reference to an
    > object after that object has been completely initialized is guaranteed
    > to see the correctly initialized values for that object's final fields.
    > -------
    >
    > Is the above reference mean '"new" operator is thread-safe for Java'?


    In my interpretation, no. There's a difference between the instant in
    time when the new operator is executed, and the instant in time when the
    constructor finishes. This issue actually comes up in double-check locking:

    http://www-128.ibm.com/developerworks/java/library/j-dcl.html

    - Oliver
    Oliver Wong, Dec 5, 2006
    #5
  6. xie bo wrote:
    >> Reference? Oh, I dunno, but I'd be willing to
    >> bet you'll find something in the JLS.

    >
    > I checked JLS and following is citation.
    > -------
    > Section 17.5 Final Field Semantics
    > ...
    > An object is considered to be completely initialized when its
    > constructor finishes. A thread that can only see a reference to an
    > object after that object has been completely initialized is guaranteed
    > to see the correctly initialized values for that object's final fields.
    > -------
    >
    > Is the above reference mean '"new" operator is thread-safe for Java'?
    >
    > Thanks!
    >


    Not necessarily. It depends, as Eric pointed out, on what the
    constructor does:

    public class SynchTest {
    static int count1 = 0;

    static int count2 = 0;

    public static void main(String[] args) {
    Runnable myRun = new Runnable() {
    public void run() {
    new SynchTest();
    }
    };

    Thread[] allThreads = new Thread[10];
    for(int i=0; i<allThreads.length; i++){
    allThreads = new Thread(myRun);
    }
    for(Thread t : allThreads){
    t.start();
    }
    for(Thread t : allThreads){
    try {
    t.join();
    } catch (InterruptedException e) {
    // IGNORE INTERRUPT
    }
    }
    System.out.printf(
    "Actual=%d count1=%d count2=%d%n",
    allThreads.length, count1, count2
    );
    }

    public SynchTest() {
    badIncrement();
    goodIncrement();
    }

    private void goodIncrement() {
    synchronized (this.getClass()) {
    count1++;
    }
    }

    private void badIncrement() {
    int x = count2;
    try {
    Thread.sleep(1000);
    } catch (InterruptedException e) {
    // IGNORE INTERRUPTS
    }
    x++;
    count2 = x;
    }
    }
    Patricia Shanahan, Dec 5, 2006
    #6
  7. xie bo

    xie bo Guest

    > In my interpretation, no. There's a difference between the instant in
    > time when the new operator is executed, and the instant in time when the
    > constructor finishes. This issue actually comes up in double-check locking:
    >
    > http://www-128.ibm.com/developerworks/java/library/j-dcl.html


    I read the article "Double-checked locking and the Singleton pattern"
    in http://www-128.ibm.com/developerworks/java/library/j-dcl.html.
    -------------------
    To show how this occurs, consider the following pseudo code for the
    line: instance =new Singleton();

    mem = allocate(); //Allocate memory for Singleton object.
    instance = mem; //Note that instance is now non-null, but has not been
    initialized.
    ctorSingleton(instance); //Invoke constructor for Singleton passing
    instance.
    --------------------

    My question: Is the out-of-order bug fixed for J2SE 1.5? (because JSR
    133 was adopted by J2SE 1.5)

    Thanks!
    xie bo, Dec 6, 2006
    #7
  8. xie bo

    Oliver Wong Guest

    "xie bo" <> wrote in message
    news:...
    >> In my interpretation, no. There's a difference between the instant in
    >> time when the new operator is executed, and the instant in time when the
    >> constructor finishes. This issue actually comes up in double-check
    >> locking:
    >>
    >> http://www-128.ibm.com/developerworks/java/library/j-dcl.html

    >
    > I read the article "Double-checked locking and the Singleton pattern"
    > in http://www-128.ibm.com/developerworks/java/library/j-dcl.html.
    > -------------------
    > To show how this occurs, consider the following pseudo code for the
    > line: instance =new Singleton();
    >
    > mem = allocate(); //Allocate memory for Singleton object.
    > instance = mem; //Note that instance is now non-null, but has not been
    > initialized.
    > ctorSingleton(instance); //Invoke constructor for Singleton passing
    > instance.
    > --------------------
    >
    > My question: Is the out-of-order bug fixed for J2SE 1.5? (because JSR
    > 133 was adopted by J2SE 1.5)


    I don't know what specific implementations do about the above, but from
    what I understand, the issue that is described in the double-check locking
    article is not considered to be a bug.

    - Oliver
    Oliver Wong, Dec 6, 2006
    #8
  9. xie bo wrote:
    >
    > My question: Is the out-of-order bug fixed for J2SE 1.5? (because JSR
    > 133 was adopted by J2SE 1.5)


    Absence of sequential consistency is not a bug. It is necessary for
    reasonable performance. In 1.5 (and in practice 1.4) is make the
    variable volatile to add sufficient happens-before relationships.
    However, singletons remain bugs and such 'clever' code is likely to be
    buggy.

    Tom Hawtin
    Thomas Hawtin, Dec 7, 2006
    #9
    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. Gabriel Rossetti
    Replies:
    0
    Views:
    1,287
    Gabriel Rossetti
    Aug 29, 2008
  2. davy zhang
    Replies:
    0
    Views:
    561
    davy zhang
    Oct 24, 2008
  3. xmllmx
    Replies:
    6
    Views:
    391
    xmllmx
    Feb 3, 2010
  4. Replies:
    1
    Views:
    310
    Brian Candler
    Aug 12, 2003
  5. John Nagle
    Replies:
    5
    Views:
    442
    John Nagle
    Mar 12, 2012
Loading...

Share This Page