• Post Reply Bookmark Topic Watch Topic
  • New Topic

object level locking in java ?  RSS feed

 
shyam ji gautam
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
let us suppose we create counter class




and second class is Counterthreads






and my main class is like




so my question is t2 willl be wait until t1 not comple because they call on same instance c1 and add method is synchronize ?


and second question is thread 3 can access synchronize method print() of instance counter c1. because what i understand that instance is lock until t1 not free it for add()
method execution so when this instance is free by t1 for add() then t3 can access it for print method() for same instance am i right ?

please suggest me


 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shyam ji gautam wrote:so my question is t2 willl be wait until t1 not comple because they call on same instance c1 and add method is synchronize ?


No. In threading, there is no guarantee of ordering. It can happen that run method for ct2 can be invoked before run method of ct1.

Secondly, you are invoking synchronized method within a for loop - which itself is not synchronized. That is, e.g. when ct1 completes first invocation of add method, and the thread is busy in incrementing the counter of for loop, ct2 can enter in the loop and invoke print method. You can easily check this by putting Thread.sleep inside for loop of run method of both threads.

shyam ji gautam wrote:and second question is thread 3 can access synchronize method print() of instance counter c1. because what i understand that instance is lock until t1 not free it for add()
method execution so when this instance is free by t1 for add() then t3 can access it for print method() for same instance am i right ?


Well, it is quite straightforward. When you say

It simply means

So, when one thread is accessing a synchronized method over one object, no other thread can invoke any synchronized method over the same object.

I hope this helps.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shyam ji gautam wrote:please suggest me

I think you're overthinking this.

A synchronized method cannot be run by more than one Thread at a time on the same instance. ALL other threads that try to access that method while it is being executed will be blocked at the point of invocation.

If more than 1 Thread is waiting for access, Java gives no guarantee as to which Thread will actually continue once the synchronization lock is released.

That''s it. No more, no less.

Therefore, since the 'for' loop in your Thread classes is not synchronized, it is perfectly possible for the following to happen:
  • ct0 starts and gets through 1 iteration of its loop. (after which point count==1).
  • ct1 starts and gets blocked.
  • ct2 starts; by which time ct0 has finished its first call to add(), and immediately gains the lock on the Counter object counter. It goes through its entire loop, during which time count still == 1 (except that you wouldn't know, because you never print it).
  • ct0 reacquires the lock on counter, and executes another iteration of its loop (after which point count==2).
  • ct1 acquires the lock on counter, and executes its entire loop (after which point count==5).
  • ct0 reacquires the lock, and executes the final iteration of its loop (after which point count==6).


  • Note that the result of count after all Threads complete is correct. Each Thread is also guaranteed to see count with a consistent value (and the correct one, given the above scenario). What you can't guarantee is what that state will be.

    Lesson:
    1. Synchronization guarantees consistency; not predictability (unless enforced).
    2. If you want predictable sequential behaviour, DON'T use Threads unless you have a very good reason.

    Winston

    [EDIT] PS: I split up your long final comment line. Very long lines in code blocks tend to screw up the windowing here.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!