This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchonization, access to object  RSS feed

 
Sudarshan Muramreddy
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I have one doubt

Let us say if there are two methods

test1() & test 2() are both are synchronized and working on the same object.

In the above case will be get race problem,To aviod shall we need to synchonize that object/variable? .

Response is appreciated.

Regards,
Sudarshan
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Synchronizing will help you avoid race conditions. For example this unsynchronized method is at risk:

If you pass in a 1 you expect it to do something. But in fact another thread could change myMemberVariable to 2 between the time we set it to 1 and test it for 1. So we set a variable and then it's a race to see if we read it before another thread changes it. Not good.

If you synchronize the method, then the whole object only allows one thread to run a method at a time. If you synchronize on some member variable then only the methods that synchronize on that variable are forced into single file execution. Here's an example of each:

It's still your job to make sure sensitive code block synchronize on the appropriate object. It won't do much good to synchronize methodOne but not methodTwo if they both modify some variable.

Many prefer the synchronized code block to the sync method because it holds a lock for a smaller span of code. You can also precisely control which methods block on which variables ... if that is really necessary your design may be a bit complex.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
[QB]
If you synchronize on some member variable then only the methods that synchronize on that variable are forced into single file execution. [QB]

Hi Stan,
Let me know if my understanding is right.
Any other synchronized block in any class that takes the same variable(if the variable had been public) as a parameter to the synchronized block will be locked until the the thread exists from this this synchronized block.

Thanks
William
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right. The variable doesn't have to be public or even a member variable of this class. The two threads just need to have a reference to the same locker instance. It could even be a parameter:

Now A and B could both have synchronized(locker) blocks. This gets pretty tricky, and totally contrived. Say I know methods (A and B) cannot run at the same time, and (C and D) cannot run at the same time, but (A and D) or (B and C) would be fine. I could sync A and B on locker1 and sync C and D on locker2. I It oughtta work out, but I've never run into anything with that particular granularity.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!