therad-safety

Discussion in 'Java' started by laredotornado@zipmail.com, Jul 26, 2006.

  1. Guest

    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, -
     
    , Jul 26, 2006
    #1
    1. Advertising

  2. schrieb:
    > 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
     
    Michael Rauscher, Jul 26, 2006
    #2
    1. Advertising

  3. wrote:

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

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jul 26, 2006
    #3
  4. 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. 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
     
    Patricia Shanahan, Jul 27, 2006
    #4
  5. 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, Jul 27, 2006
    #5
  6. 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, Jul 27, 2006
    #6
  7. Hi Stefe,

    to refine my answer:

    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.

    Bye
    Michael
     
    Michael Rauscher, Jul 27, 2006
    #7
  8. 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.
     
    Steve Wampler, Jul 28, 2006
    #8
    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. Hans

    What is thread safety?

    Hans, Oct 11, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    590
    Sahil Malik
    Oct 12, 2004
  2. George Ter-Saakov

    LiteralControl thread safety.

    George Ter-Saakov, Apr 5, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    347
    Martin Dechev
    Apr 6, 2004
  3. Steven Baeten

    ADODB.connection safety settings error

    Steven Baeten, May 7, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,843
    Mary Chipman
    May 9, 2004
  4. Raymond Du

    newbie question on "Type Safety"

    Raymond Du, Jun 21, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    318
    M. Zeeshan Mustafa
    Jun 21, 2004
  5. sickness
    Replies:
    0
    Views:
    325
    sickness
    Jun 15, 2006
Loading...

Share This Page