therad-safety

[laredotornado]

Hi, I was asked this in an interview. Given the following, how would I
make the below code "thread safe"?

public class MyClass {
private Foo _foo;

public void setFoo(Foo foo) {
_foo = foo;
}

public Foo getFoo() {
return _foo;
}
}


Thanks, -

 

[Michael Rauscher]

Hi, I was asked this in an interview. Given the following, how would I
make the below code "thread safe"?

public class MyClass {
private Foo _foo;

public void setFoo(Foo foo) {
_foo = foo;
}

public Foo getFoo() {
return _foo;
}
}

declare _foo to be volatile *or* make the methods synchronized *or*
access _foo only within synchronized blocks.

Bye
Michael

 

[Christopher Benson-Manica]

Hi, I was asked this in an interview. Given the following, how would I
make the below code "thread safe"?

In addition to the other answers, you could use an AtomicReference to
hold the Foo, assuming Java 1.5 is available.

 

[Patricia Shanahan]

Hi, I was asked this in an interview. Given the following, how would I
make the below code "thread safe"?

public class MyClass {
private Foo _foo;

public void setFoo(Foo foo) {
_foo = foo;
}

public Foo getFoo() {
return _foo;
}
}

The answers you have already been given are good as far as this code is
concerned. However, if I saw this in a real program and wanted to make
it thread-safe I would also investigate Foo, and the callers of getFoo
and setFoo.

The reasoning is that the MyClass code was obviously written without
attention to thread safety. It is entirely possible that related code
was also written without regard to thread safety, and MyClass will not
work correctly unless the Foo handling is thread-safe.

Patricia

 

[Steve Wampler]

The answers you have already been given are good as far as this code is
concerned.

Out of idle curiousness, would someone mind explaining just what could go
wrong with the above code (as written) when used in a threaded environment?
I understand why the answers are good in general, but would like to
understand what behavior they are preventing in this simple class.

Thanks!

 

[Steve Wampler]

....
Out of idle curiousness, would someone mind explaining just what could go
wrong with the above code (as written) when used in a threaded environment?
I understand why the answers are good in general, but would like to
understand what behavior they are preventing in this simple class.

Ah, to partially answer my own question: without volatile, an optimizer may
not realize that _foo can be changed in another thread and perform
an optimization that results in the 'external' value change being ignored - right?

Is that true of using synchronization as well? It prevents such optimizations?
(Or is there a separate issue that is addressed with the synchronization?)
Same questions about using an AtomicReference, of course.

Thanks!

 

[Michael Rauscher]

Hi Stefe,

to refine my answer:

Ah, to partially answer my own question: without volatile, an optimizer may
not realize that _foo can be changed in another thread and perform
an optimization that results in the 'external' value change being ignored - right?

Yes. Without volatile each thread may hold the variable in a "private
working memory". A volatile field is "synchronized" with main memory on
each access.

Is that true of using synchronization as well? It prevents such optimizations?

No, it doesn't prevent optimizations. In a synchronized method/block the
"synchronization" of the field with main memory is done when the lock is
obtained or released.

Bye
Michael

 

[Steve Wampler]

Hi Stefe,

to refine my answer:



Yes. Without volatile each thread may hold the variable in a "private
working memory". A volatile field is "synchronized" with main memory on
each access.


No, it doesn't prevent optimizations. In a synchronized method/block the
"synchronization" of the field with main memory is done when the lock is
obtained or released.

Thanks!! I was wondering how synchronization would help with the volatility
of _foo - now I see it might be more efficient if there was a *lot* more code
inside setFoo or getFoo that referenced _foo.

Thanks again.