Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Thread safety of this example.  RSS feed

 
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there any reason to need to synchronize in this case (see comment in the code)?

 
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
no. Why would you think so?
 
Darrin Smith
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mr. C Lamont Gilbert:
no. Why would you think so?



I just ran across some code by someone with more recent threading experience than I have and I thought maybe I forgot something!

To me since this was all local it should be fine, but I've been away from threading for quite a while so...
 
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, the synchronized block doesn't make any sense, as every thread would creates its own stringbuffer object, anyway. There is no way two threads could try to get a lock on the same buf object.
 
Darrin Smith
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
No, the synchronized block doesn't make any sense, as every thread would creates its own stringbuffer object, anyway. There is no way two threads could try to get a lock on the same buf object.



I think his thoughts were that the object being passed in to method2 might be exposed to concurrent modification in other methods not seen in this example and locking it down this way would prevent it.

Again, I thought as you did but...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Darrin Smith:

I think his thoughts were that the object being passed in to method2 might be exposed to concurrent modification in other methods not seen in this example and locking it down this way would prevent it.



But the way the code is written, by synchronizing on the locally created buf object, there is no locking that would prevent it.
 
Darrin Smith
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


But the way the code is written, by synchronizing on the locally created buf object, there is no locking that would prevent it.



So maybe he is right in that a concurrent modification can take place to the SubObject passed in to method2, but instead of synchronizing on the StringBuffer, he should have used the SubObject reference itself?
 
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, synchronizing on the SubObject might possibly be useful, though it's hard to say without knowing more about how it's used. Whereas synchronizing on the StringBuffer is of no possible use to anyone.

I also note that the entire method2 could be shortened to:
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!