• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Marcus Green #3 Q19 (Thread question)

 
Larry Lecomte
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question states:
What will happend when you attempt to compile and run the following code?
public class Tux extends Thread{
static String sName = "vandeleur";
public static void main(String argv[]){
Tux t = new Tux();
t.piggy(sName);
System.out.println(sName);
}
public void piggy(String sName){
sName = sName + " wiggy";
start();
}
public void run(){
for(int i=0;i < 4; i++){
sName = sName + " " + i;
}
}
}
1) Compile time error
2) Compilation and output of "vandeleur wiggy"
3) Compilation and output of "vandeleur wiggy 0 1 2 3"
4) Compilation and probably output of "vandelur" but possible output of "vandeleur 0 1 2 3"
The answer says:
4) Compilation and probably output of "vandelur" but possible output of "vandeleur 0 1 2 3"
Why is the answer POSSIBLE output of "vandeleur 0 1 2 3" ? I was sure that this was ALWAYS in the
output, because the thread is NOT a daemon thread...
 
Dave Vick
Ranch Hand
Posts: 3244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Larry
The main Thread and the Thread tux both have the same priority and becasue thread scheduling is OS dependent either one could preempt the other at any time. Or the main Thread could finish running before the tux Thread modifys the String. Because the String starts with the value of vandeleur, vandeleur will alwasy be printed. IF the tux Threads' runs before the main Thread prints the String then the String may not be just vandeleur.
Hope that helps
 
Anthony Villanueva
Ranch Hand
Posts: 1055
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please see this thread.
 
Marcus Green
arch rival
Rancher
Posts: 2813
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Larry, I understand that this question can seem confusing but it covers an important point. No matter how many times you run this code yourself and get the expected result it does not mean that the result you see is guaranteed. The thread related topics on the exam are quite narrow, but you need to understand them well.
 
Ron Newman
Ranch Hand
Posts: 1056
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus, would you agree that the following are also possible, though unlikely, outputs from your program?
"vandeleur 0"
"vandeleur 0 1"
"vandeleur 0 1 2"
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ron:
I would agree with you. Can we define a string object as syncronized to avoid such output?
[ September 23, 2002: Message edited by: Barkat Mardhani ]
 
Ron Newman
Ranch Hand
Posts: 1056
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
String is a final class. You can't define a subclass with synchronized methods. Also, String objects are immutable so there is no point to synchronizing access to them.
What you probably want to do instead is synchronize access to the String variable Tux.sName. Since this is a static variable, you'll need either static synchronized methods or blocks that start with "synchronized (Tux.class)" .
[ September 23, 2002: Message edited by: Ron Newman ]
[ September 23, 2002: Message edited by: Ron Newman ]
 
Marcus Green
arch rival
Rancher
Posts: 2813
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ron, yes I agree those are possible alternative outputs.
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ron:
q1: String objects are immutable. Are String members also immutable. If yes, why following is allowed:
 
Ron Newman
Ranch Hand
Posts: 1056
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This statement creates a new String object whose contents are the two argument strings appended together.
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but sName is class member as well as a string type. So if string are not mutable, class members can not be either...Right?
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Barkat,
sName is a reference to a String object.
After sName = sName + "wiggy"; it's the reference
that has changed. It's now pointing to a new String object, as Ron said.
BTW, if sName was final, the new String object could not be assigned to the sName variable.
-Barry
 
Shishio San
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
the sName inside the method refers to the method's argument. The class member sName has been shadowed and it was not affected by the assignment (sName = sName + "wiggy");
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shishio San said: the sName inside the method refers to the method's argument. The class member sName has been shadowed and it was not affected by the assignment (sName = sName + "wiggy");

Exactly Shishio San! The sName inside the method is pointing to the new string, but the member sName is still pointing to the old one.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic