synchronization issue

[Chandra Bhatt]

Hi,

public class Person
{
    String firstname, lastname;
 
    public String toString()
    {
StringBuffer sb = new StringBuffer();
sb.append(firstname);
sb.append("-");
sb.append(lastname);
return sb.toString();
    }
}

The source says, the method toString() is thread safe and StringBuffer can
be replaced with StringBuilder to increase the performance.

I don't understand this. Please help.

Source: Enthuware


Thanks,

[Vassili Vladimir]

Hi,

Because the methods of StringBuilder are not synchronized ...

Best of luck ...

[Chandra Bhatt]

Thanks Vassilli,

But my question was "How come method toString() thread safe?"
StringBuilder can increase the performance because not synchronization overhead with its methods like its brother StringBuffer.


Please consider my question.


Thanks,

[megha joshi]

But my question was "How come method toString() thread safe?"

Its thread safe becuase all StringBuffer methods are implicitly
synchronized. So toString() method is overriden to be synchonized implicitly.

  
class Parent{
    
    public String toString()
    {return "Suppose I am Object toString";}
}
class Child1 extends Parent{
    public synchronized String toString()
    {return "Suppose that I am StringBuffer Tostring";}
}
  

Does tht answer the question ? Or am I completely off the track
in understanding it

Thanks,
Megha

[Chandra Bhatt]

Thanks Megha for reply to this almost deserted thread,

But I miss to catch the points (It's my weakness anyway), the source says
you can replace StringBuffer with StringBuilder to increase the performance.
Of-course it is alright. I don't have trouble with it.

But my question is, would it remain thread safe after replacement?
My doubt runs around the toString method, whether it is thread safe or
not; In case if it is doing all the operations using StringBuffer is is thread safe, because of its all sync internal methods.

Whole doubt is wrapped with (like decorator pattern ) the following,
no two threads can access a method of the StringBuffer at a moment together
but still the whole method toString() is still not synchronized, two threads may still intermingle the operation that is happening inside the toString() method.

I call it critical area where modification is being done.

Please and please do something with this issue.


Thanks
[ May 05, 2007: Message edited by: Chandra Bhatt ]

[Henry Wong]

Originally posted by Chandra Bhatt:

The source says, the method toString() is thread safe and StringBuffer can
be replaced with StringBuilder to increase the performance.

I don't understand this. Please help.

The "sb" reference variable is a local variable, which references an object that does not escape the method. Meaning that the object referred to by the "sb" variable can't be accessed by any other thread.

Or in other words, the toString() method is thread safe because different threads calling the method will get local copies of objects to be used internally. There is no object sharing, and hence, synchronization is not necessary.

Henry
[ May 05, 2007: Message edited by: Henry Wong ]

[Chandra Bhatt]

Exactly Henry,

That is what I was expecting somebody to answer. sb is internal to method and
every thread will get local copies of objects to use with.


I liked that!



Thank you very much for clearing my doubts,
[ May 05, 2007: Message edited by: Chandra Bhatt ]

[John Stone]

firstName and lastName are shared, but since they are both immutable, and assignment of reference is most likely an atomic operation,
toString can be considered as thread-safe, because there is no way to get into inconsistent state

[Chandra Bhatt]

Originally posted by John Stone:
firstName and lastName are shared, but since they are both immutable, and assignment of reference is most likely an atomic operation,
toString can be considered as thread-safe, because there is no way to get into inconsistent state

Hi John,

I find point in what you said. "Atomic operation" I simply like this.
But I couldn't get you exactly regarding the immutability issue.

If one thread modifies the firstname and last name outside the method toString(), why wont it affect the meaning of toString() method.
Anyhow, all the threads will be sharing the same member variables.

Please clarify what you said.

[Henry Wong]

Originally posted by John Stone:
firstName and lastName are shared, but since they are both immutable, and assignment of reference is most likely an atomic operation,
toString can be considered as thread-safe, because there is no way to get into inconsistent state

firstName and lastName are not declared as volatile, so the toString() method may get an older version of the object. There is also a race condition, in that one name may be changed, but not the other, giving you a weird name combination.

However, you are right, in that reference assignments *are* atomic. Either it will get the old value or the new value, it will not get a reference value that is a combination of the two possible references.

Regardless, this problem exist whether you are using StringBuffer or StringBuilder.

Henry
[ May 05, 2007: Message edited by: Henry Wong ]

[John Stone]

Originally posted by Chandra Bhatt:



Hi John,

I find point in what you said. "Atomic operation" I simply like this.
But I couldn't get you exactly regarding the immutability issue.

If one thread modifies the firstname and last name outside the method toString(), why wont it affect the meaning of toString() method.
Anyhow, all the threads will be sharing the same member variables.

Please clarify what you said.

I meant that, only way you can change String object is to make new and swap references. (So the change would appear as atomic)

from javadoc on string class:

Strings are constant; their values cannot be changed after they are created. String buffers support mutable strings. Because String objects are immutable they can be shared.

[Chandra Bhatt]

Hi,

Henry I will request you to give me an example of this race condition where we could get the old or new value. I understand this race condition as dependency of final result on the order of statement execution.

I think this will help a lot.


Thanks,
[ May 05, 2007: Message edited by: Chandra Bhatt ]

[Chandra Bhatt]

If we take appending both firstname and secondname to the StringBuffer or StringBuilder, as one, is this atomic operation in that context? or there may be inconsistency in the result.


Henry:

firstName and lastName are not declared as volatile, so the toString() method may get an older version of the object. There is also a race condition, in that one name may be changed, but not the other, giving you a weird name combination.

That goes to my brain easily though
Thanks,
[ May 05, 2007: Message edited by: Chandra Bhatt ]

[John Stone]

Originally posted by Henry Wong:


firstName and lastName are not declared as volatile, so the toString() method may get an older version of the object. There is also a race condition, in that one name may be changed, but not the other, giving you a weird name combination.

However, you are right, in that reference assignments *are* atomic. Either it will get the old value or the new value, it will not get a reference value that is a combination of the two possible references.

Regardless, this problem exist whether you are using StringBuffer or StringBuilder.

Henry

[ May 05, 2007: Message edited by: Henry Wong ]

Agreed. Let me then repeat the question: "Is toString thread-safe"?

If this object is not used in some thread-safe context, then I guess it will be never thread safe since its members can be changed at any time without any chance to control access.

It would be much easier, if names had private access modifiers.

[Henry Wong]

Envisioning the race condition isn't that hard...

public class Person {
    String firstname, lastname;
    
    public void setNames(String first, String last) {
        firstname = first;
        lastname = last;
    }
 
    public String toString() {
StringBuffer sb = new StringBuffer();
sb.append(firstname);
sb.append("-");
sb.append(lastname);
return sb.toString();
    }
}

Imagine one thread calls the setNames() method, it sets the first name, but before it can set the lastname, the toString() method is called by another thread. The toString() method may return a value that has the new first name but the previous last name.

Henry