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 Shanahan wrote:
> wrote:
>> 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.

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 --
The gods that smiled on your birth are now laughing out loud.

Steve Wampler wrote:
> Patricia Shanahan wrote:
>>> 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; } }
....
> 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!
--
Steve Wampler --
The gods that smiled on your birth are now laughing out loud.

Steve Wampler schrieb:
>> 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?

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.

Michael Rauscher wrote:
> Hi Stefe,
>
> to refine my answer:
>
> Steve Wampler schrieb:
>> 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.

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.
--
Steve Wampler --
The gods that smiled on your birth are now laughing out loud.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!