Is 'new' operator thread-safe?

[xie bo]

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!

 

[Thomas Richter]

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

 

[Eric Sosman]

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.

 

[xie bo]

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.

 

[Oliver Wong]

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.

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

 

[Patricia Shanahan]

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;
}
}

 

[xie bo]

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!

 

[Oliver Wong]

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.

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

 

[Thomas Hawtin]

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