current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

I had an interview few weeks back, and I was asked to write a code with Setters and Getters. I had written the following code;

// Just an example

Class ABC{
    private int num;

    public void setNum(int givenNum){
        this.num = givenNum;
    }

    public int getNum(){
        return num;
    }

    public ABC(){
        num = 0;
    }


    public static void main(String [] args){
        ABC object1 = new ABC();
        ABC object2 = new ABC();

        object1.setNum(5);
        System.out.println(object1.getNum());
        System.out.println(object2.getNum());
    }

}

Now I was told, that "object1" can change the value for "object2.Num". But I was not in agreement with this, I believe another thread which has access to object2 can change the value of object2.Num but not object1.

In the above case, I would have synchronized the setter method, or use the synchronized block inside the setter method while setting/changing the value, but I could not understand the concept of object1 changing the value of object2.Num.

I was just curious if I was missing on something. If so I would really appreciate any help regarding the same.

share|improve this question
1  
Sounds to me that you might be better off not working for them... –  Drake Clarris Jul 5 '13 at 14:49
    
@DrakeClarris Yeah, that was a surprise for me, when the question was asked that way. I just wanted to confirm if I was thinking in the right direction, or was I missing something. Thanks. –  JNL Jul 5 '13 at 16:08

3 Answers 3

up vote 0 down vote accepted

If class ABC can be accessed from more than one thread, you will need to synchronize both setNum and getNum. Until you leave a synch block, the new value of num need not be available to any other thread. Until you enter a synch block, changes so made in another thread will not be visible in this one. And in Java (but not C#), both both blocks must (according to the rules, the JLS) be synched on the same object. (Of course, if you make the methods synchronized, they'll synch nicely on this instance of ABC.)

This might have been the point your interviewer was making.

(And making 'num' volatile (private volatile int num) would do much the same thing.)

share|improve this answer
    
I agree to your point that synchronizing the method would be thread safe. But little confused on synchronizing the getter? Do you mean the getNum() method should be synchronized so that say if thread A accesses "Num" thread B should not be able to change the value of "Num"? –  JNL Jul 5 '13 at 19:19
    
@JNL: No. If thread B changes the value of num and getNum() isn't synchronized, thread A might not see the change when it calls getNum. To put it crudely, leaving a synch block forces changes out of registers and caches and into main memory. Entering a synch block forces the thread to refresh all its caches and registers. Leave out either step and one thread's changes may not be be seen by the other thread. Personal experience suggests there's a rather variable delay (nothing to hours) between B making a change and the change being seen by A. –  RalphChapin Jul 5 '13 at 19:32
    
Appreciate you sharing the experience. But now coming back to the question, how would "object1" change "object2.Num". I believe it still cannot be done, correct? –  JNL Jul 5 '13 at 19:36
1  
@JNL: Correct. Joachim Sauer says it best. I do wonder if there isn't a misunderstanding somewhere. People sometimes confuse objects and threads. They may have been trying to talk about two threads accessing the same object. (Indeed, without synchronization, as I've explained, the two threads might see completely different objects--or at least different sets of data. Rather hard to say. –  RalphChapin Jul 5 '13 at 19:48
up vote 2 down vote

If all you have is a reference to object1, then no, you can't change object2.num.

The only thing that comes somewhat close to what you describe would be things like this:

public void swap(ABC other) {
  int num = this.num;
  this.num = other.num;
  other.num = num
}

Suche a code could modify two ABC objects: this (i.e. the object on which it's called) and other (the parameter). But this doesn't have anything to do with multithreading either.

share|improve this answer
    
Agree, that only if "object1" was referenced to "object2", then object1 would change object2.Num. Also the above is just a simple example, say if the above Num implies "Balance" of a bank account, so multithreading would come into picture. At that point synchronizing the setter or adding a synchronized block to {this.num = givenNum; } would sove the issue? Thats correct right? –  JNL Jul 5 '13 at 14:19
1  
synchronizing a setter alone rarely solves any issues. Because the setter call alone is usually not what you want to happen atomically. What you want (in the case of a balance) is that two modifications of separate bank accounts are atomical, which means you need a single synchronized block about both setter calls. –  Joachim Sauer Jul 5 '13 at 14:21
    
So do you recommend Synchronized block for those lines of code who would be changing/setting the balance value? –  JNL Jul 5 '13 at 14:29
up vote 1 down vote

Synchronization is not the relevant concept here. You synchronize things to prevent errors caused by the unforeseen order of actions caused by interleaving different threads. The classical example is decreasing the balance of one bank account and increasing another by the same amount, which can lose information (money) if not done atomically. But this code merely assigns an integer, which is already atomic, so the point is not inconsistency.

They were probably talking about access control and the somewhat surprising fact that private means "private to all instances of the class" and not "private to to the owning instance only" in java. object2 can change the value of a field in object1 if it has a reference to object1. But this has nothing to do with synchronization.

share|improve this answer
    
I agree with your point. I gave the interviewer the same explanation, but then the Interviewer said, how about "Synchronization", So I believed he wanted to move into that direction just to see if I knew that concept. But I once again told him, that I still don't think "object1" can change "object2.Num" unless we do object1=object2 and then go ahead. –  JNL Jul 5 '13 at 14:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.