• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread safety of this example.

 
Darrin Smith
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)?

 
Mr. C Lamont Gilbert
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...
 
Ilja Preuss
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?
 
Jim Yingst
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:
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!