File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Concept of locks and synchronization !

 
Shafkat Talli
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, have my exam tomorrow, wish me luck, i am really nervous, just been studyin for 2 weeks, but have some java experience from be4. Anyway i have my fingers crossed
My question is:
I have some problems understanding the way wait() method works on objects. I understand the processing of code, but have some problem with the general understanding.
Plz tell me if my view on this code is right or wrong:
There are two threads here ThreadA and ThreadB. Thread A starts of running first, it calls and makes a ThreadB object, and executes the ThreadB on line 4.

ThreadA continues to process, and on line 6 it becomes the owner of object b (with other words it gets the lock on this object). ThreadA now waits until it gets notified, and gets runnable again and a candidate to run. When ThreadB gets to line 24, it notifies ThreadA.
MY QUESTIONS NOW ARE:
-it is said that a call to wait() on an object, makes a thread leave the running state. As ThreadA did in the example. BUT I ALSO READ SOMEWHERE
that when the wait()-method is invoked on an object, the thread executing that code gives up its lock ? this i dont understand, how can one thread get to be a owner of a lock and at the same time release all its locks ??? i dont know what im saying but im confused
-by the way shouldnt "int total" instance variable in ThreadB (line 17) be private ? cause some other class in this same package could get access to it and corrupt it ?

[ Jess added UBB [code] tags to preserve whitespace, check 'em out! ]
[ August 20, 2003: Message edited by: Jessica Sant ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. At line 6 thread A acquires the lock. At line 9, when thread A invokes wait(), thread A releases the lock.
Now that thread A has released the lock, thread B can acquire the lock at line 20.
When thread B invokes notify() at 24, thread B still has the lock. Thread A cannot return from wait() until thread B has released the lock and thread A has reacquired the lock.
At line 25 thread B releases the lock. Then thread A acquires the lock and returns from wait() at line 9.
2. You might wonder why thread A acquires the lock at line 6 only to release it at line 9.
Suppose thread A invoked wait() without a lock. Before thread A actually blocks, thread B might invoke notify(). Then thread A blocks, the notify() is lost, and thread A never awakes.
[ August 20, 2003: Message edited by: Marlene Miller ]
 
Jose Botella
Ranch Hand
Posts: 2120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no certainty in which thread will grab the lock first. This might be hard to believe it, but the scheduler might choose the ThreadB to complete before main could have entered synchronized(b).
Shafkat, I regret to say that Threads are very important in the exam. You might want to consider postponing it.
Threads : doing to or more tasks at once.
Concurrency
 
Shafkat Talli
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah i understand the code now, thanx, for ur help, and i think i have to take it now, have postponed it too much
GOD HELP ME, HEHEH
 
Deep Chand
Ranch Hand
Posts: 133
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Please correct me if i'm wrong:
in the above code, there is a possibility of a deadlock. ThreadA may be swapped out by the schdeuler just after it calls start() on ThreadB. ThreadB will then get the it's own lock and finish execution and does notify() and at that time, there is no thread waiting for that monitor. After this point, Thread continues execution and does a wait() on ThreadB but now ThreadB is done execution. So may be ThreadA will be in the wait() state forever or ???
Java experts - does the above makes sense???
Thanks,
Deep
 
Shafkat Talli
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmm i wonder too, is it possible that Thread1 one could in some circumstances wait 4ever ?
 
Jose Botella
Ranch Hand
Posts: 2120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it is possible. In fact that is what I was referring to in my previous post.
It is also advisable to place wait within a loop.
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a slight possibility that ThreadB locks on object b first. In that case notify will be issued before wait is executed. Hence after wait is executed, ThreadA will wait for ever to be notified. To demonstrate this possibility, I introduced a delay in ThreadA.
 
Shafkat Talli
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jose, i did give the exam today, resulting in 86 % jipppi
 
Jose Botella
Ranch Hand
Posts: 2120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Congratulations
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic