• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

peek() and pop() in the Stack class - why synchronize?

 
Ranch Hand
Posts: 216
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been looking at the code of the java.util.Stack class and I'm not sure why these two methods are synchronized. Can anybody please explain it to me? Thanks in advance for your time.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stack was one of the original collection classes, along with Vector, Hashtable etc. All those collection classes were designed to be "threadsafe".
Imagine what would happen if two threads have access to the same Stack. If the stack is not threadsafe, then one might be half way through "push"ing an element, when another tries to "pop" one. The result could be a real mess.
So the methods are synchronized, to make sure that each operation completes before another thread may do anything with that object.
 
ernest fakudze
Ranch Hand
Posts: 216
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Frank, it is clear now
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That said, the Java people decided that it was a mistake to synchronize them and the Collections framework implementations are now all unsynchronized.
Two threads trying to modify the Stack at the same time won't be able to leave it in an unpredictable state, since its methods are synchronized. BUT another thread could quietly push() some things on during the middle of your own threads execution. 99% of the time it's better to lock it yourself to avoid breaking your own invarients, and as a side effect the collection's invarients won't break either. The unnecessary synchronization just slows the class down when you're working in an single-thread environment.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And the other reason why collections are now unsynchronized by default: if you're not using multiple threads, synchronization is an unnecessary performance drain. Typically a minor one, but in some situations it can be fairly noticable. Better to leave it out by default, and let the programmer synchronize at the level appropriate to the application, if necessary.
 
Ranch Hand
Posts: 1056
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I read somewhere that StringBuffer is synchronized. Is that really true? If so, it seems like a serious waste, for the same reasons.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's true, according to the API (and also the source code). I agree, it's wasteful. But since it's in the API, they can't really change it now. And unfortunately StringWriter is just a wrapper around a StringBuffer, so it has the same problem. However the API here is more ambiguous, so it's possible they could replace this with a more efficient implementation sometime in the future. Perhaps it would be worthwhile to try making custom versions of these classes. One could simply re-use the existing source code but remove the "synchronized" parts. (Although StringWriter's getBuffer() method would have to copy data to a real StringBuffer first, and changes to the copy would have no effect on the original (unlike the current case with changes to the buffer returned by getBuffer()). Perhaps there's a third-party class already out there somewhere...
 
Ron Newman
Ranch Hand
Posts: 1056
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It seems especially wasteful since String concatenation (overloaded "+" operator) uses StringBuffer to do its work.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic