Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Let me handle the first code snippet's questions in reverse order:
Angus Ferguson wrote:Is Thread a static class
No. Thread is a top level class, it can't be static. The code is this:
That code snippet creates a new Thread object, then calls the new Thread's start() method. It simply does not create a reference to the Thread it creates because it does not ever need to use the reference again. That code is identical to this:
Angus Ferguson wrote:Why it doesn´t call printTwo()
There are two threads in this example. The main thread, which calls the main() method, and the new thread created in the code discussed above. The main thread calls printTwo() and the new thread calls printOne(). This is part-and-parcel to the entire example, which relies on the two different threads getting the two locks in reverse order. So the new thread calls printOne() which gets the locks in the order s1 -> s2 and the main thread calls printTwo() which gets the locks in the order s2 -> s1.
Angus Ferguson wrote:Why the thread sleeps
Deadlock (and many threading issues) is really a timing problem. It is quite likely that one or both of the threads could happen so quickly that you would never see the effect of the deadlock, because one thread completely finishes before the other thread starts. Adding the sleep() here just forces the example to slow down to make sure the problem occurs.
Angus Ferguson wrote:Does it means that "s1" is waiting meanwhile "s2" is working??
No. Every object has a 'lock' which only one thread at a time can hold. The synchronized(s1) statement says 'take the lock associated with the s1 Object and hold it for this (current) thread.' If another thread (say the main thread) also tries to get the lock associated with s1 (by using synchronized(s1)) then it must wait for this current thread to finish and release the lock before it can get the s1 lock.
And that is the crux of deadlock and the example. There are two (or more) locks being taken in different orders by different threads. The main thread takes the lock associated with s2, and the new thread takes the lock associated with s1. Then the main thread tries to take the lock for s1, but it can't because the new thread already has it. So the main thread must wait for the s1 lock. Problem is, the main thread already has the s2 lock while it is waiting for the s1 lock and the new thread wants to get the s2 lock. The new thread can't get the s2 lock because the main thread already has it. Since the main thread is waiting on the s1 lock (which new thread has) and the new thread is waiting on the s2 lock (which main thread has) both threads are stuck, unable to progress.
Angus Ferguson wrote:What a deadlock is?
I hope the above paragraph helps. Although I think the second code snippet might not be a good example of deadlock (a cursory looks makes me think it might not actually go into deadlock).
Steve Luke wrote:I think the second code snippet might not be a good example of deadlock (a cursory looks makes me think it might not actually go into deadlock).
I am pretty sure it will not go into deadlock. I think it would just take 32 minutes (each thread.sleep() is for >16 minutes) for it to complete its job once, and even so it provides no feedback. It also would end up going into an infinite loop, not that you would notice before getting bored of the sample and killing it off.
He loves you so much! And I'm baking the cake! I'm going to put this tiny ad in the cake:
Free, earth friendly heat - from the CodeRanch trailboss