Hi all. In the code below t has a lock on l object when it enters the synchronized method1 at line 22(or at least thats what I think) and then waits at line 25. But how come t2 was able to execute method2 at line 31 which is also a synchronized method? My understanding (based on the K&B book) is that every object in Java has a built-in lock that only comes into play when the object has synchronized method code. Since there is only one lock per object, if one thread has picked up the lock, no other thread can enter the synchronized code (which means any synchronized method of that object) until the lock has been released.
However, modifying the code a bit to use sleep in lieu of wait at line 25 does lock the object. How is it that lock works if I use sleep and not for wait?
Hi, calling wait() on an object instance sends a currently executing thread to a waiting pool while making it relinquish the lock on this object. After this point, if another thread attempts to enter the code that is sync-ed on the same object, it'll succeed. In your example, it's method method2(). Calling notify() lets a waiting thread know that the lock on the object it's blocked on is about to be released soon (but not right away). So, while thread 1 is blocked, the lock becomes available to thread 2. Notice, however, that nothing is guaranteed flow wise in your first example. If thread 2 is chosen to run first, the program will never complete blocking in method1()! The second example uses Thread.sleep() to put a currently executing thread (obviously, thread 1) to sleep. While sleeping, a thread retains all its locks, so there's no way that thread 2 completes if thread 1 started first. And again, nothing is guaranteed by the scheduler. Thread 2 may run before thread 1.
I just found out I can lock just a portion of my method as opposed to the entire object. Line 29 uses the lock of another object rather than use its own. That other object is declared static on line 18 so that no two threads can lock on the same piece of code otherwise using synchronize would be useless. So while that portion is locked other threads can also lock the same object using the object's own lock or again use some other object's lock. I'm just blown away on how powerful thread stuff is. Would anybody know a good book on good multi-threaded design?
Dennis, what you've mentioned above is a popular programming technique - synchronizing on a dummy object. It's got its own pros and cons, and that discussion has been up for awhile. Synchronizing your code is a trade off of performance vs. consistency or security if you will. What code needs synchronization is solely up to the designer. You may be interested in perusing the following two maestros of concurrent programming: Paul Hyde Doug Lea Both are very fundamental helping you create intuitive understanding of threads.