aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Concept of locks and synchronization ! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Concept of locks and synchronization !" Watch "Concept of locks and synchronization !" New topic
Author

Concept of locks and synchronization !

Shafkat Talli
Ranch Hand

Joined: Aug 01, 2003
Posts: 30
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 ]

---------------------------<br />Shafkat Talli<br />SCJP 1.4, August 2003.
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
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

Joined: Jul 03, 2001
Posts: 2120
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


SCJP2. Please Indent your code using UBB Code
Shafkat Talli
Ranch Hand

Joined: Aug 01, 2003
Posts: 30
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

Joined: Dec 17, 2002
Posts: 133
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

Joined: Aug 01, 2003
Posts: 30
hmm i wonder too, is it possible that Thread1 one could in some circumstances wait 4ever ?
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
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

Joined: Aug 05, 2002
Posts: 787
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

Joined: Aug 01, 2003
Posts: 30
Jose, i did give the exam today, resulting in 86 % jipppi
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Congratulations
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Concept of locks and synchronization !