• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

synchronization issue

 
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,



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,
 
Ranch Hand
Posts: 1585
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Because the methods of StringBuilder are not synchronized ...

Best of luck ...
 
Chandra Bhatt
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,
 
Ranch Hand
Posts: 206
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



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.



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

Thanks,
Megha
 
Chandra Bhatt
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author
Posts: 23928
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author
Posts: 23928
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:
 
Chandra Bhatt
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author
Posts: 23928
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Envisioning the race condition isn't that hard...



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
 
Today you are you, that is turer than true. There is no one alive who is youer than you! - Seuss. Tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic