synchronization

[Victor Santos]

Hi all !!!
Can somebody help me with the following code ?

class ThreadA 
{
  public static void main( String[] r ) 
  {
    ThreadB b = new ThreadB() ;
    b.start() ;
    synchronized( b ) 
    {
      try 
      {
        System.out.println( "Waiting for b to complete..." ) ;
        b.wait() ;
      }
      catch( InterruptedException e ) {}
    }
    System.out.println( "Total is : " + b.total ) ;
  }
}
 
class ThreadB extends Thread 
{
  int total ;
  public void run() 
  {
    synchronized( this ) 
    {
      for( int i = 0 ; i < 100 ; i++ ) 
      {
        total += i ;
      }
      notify() ;
    }
  }
}

In the main method ThreadB is started , so it is in the runnable state ,right ? If it was selected by the scheduler in the moment it was started it will be in the running state and its run method will be called , right ? In the run method notify is called but I think that there will not be any thread waiting for ThreadB if it were selected at the moment it enterend at the running state. So Threadb completes and we get back to the main() . In the synchronized block b calls wait . Does exist the risk of ThreadA stay blocked forever ?

Edited by Corey McGlone: Added CODE Tags
[ August 10, 2004: Message edited by: Corey McGlone ]

[Murtuza Akhtari]

Once you execute the b.start() method call....it will create a new stack trace....but this however does not mean that the main method will will give way to the thread b...

So since the main method is already running....it will keep executing till it hits the b.wait() call....

Of course thn thread b will execute and complete before the execution returns back to main()

So to answer your question.....the main thread will not be held back !!
It will complete its execution.

However if you assign a priority to the thread b and then call start like so....

ThreadB b = new ThreadB();
b.setPriority(10);   
b.start();
...

then of course....the main thread will yield to thread b and it will never complete...since thread b has already completed like you say...
[ August 10, 2004: Message edited by: Murtuza Akhtari ]

[Sharanya Sharma]

Hi,

I have the same doubt. Yae, though the main thread is exceuting it is not guarenteed that it will continue execution. ThreadB may run before the main even enter the synchronized block. The setpriority is not necessary, though it may sort of make it easy to understand that ThreadB may complete execution before main.

I have seen such examples in the K & B book. Please clarify.

-sharanya

[Corey McGlone]

Well, I did a little testing and I have to say that I'm a little unsure of the results. Regardless, here's what I've found.

I modified the original program slightly to look like this:

public class ThreadA 
{  
    public static void main( String[] r )   
    {    
        ThreadB b = new ThreadB();    
        b.start();
            
        
        synchronized( b )     
        {
            try { b.wait(); } catch (InterruptedException e) {}      
            System.out.println("2");
            try       
            {      
                System.out.println( "Waiting for b to complete..." ) ;
                b.wait() ;        
            }      
            catch( InterruptedException e ) {}    
        }    
        System.out.println( "Total is : " + b.total ) ;  
    }
} 
 
class ThreadB extends Thread 
{  
    int total ;  
    public void run()   
    {    
        synchronized( this )     
        {      
            for( int i = 0 ; i < 100 ; i++ )       
            {        
                total += i ;     
            }      
            notify() ;    
            System.out.println("1");
        }  
    }
}

There were two major changes made to this program. First and foremost, I added an invocation of wait() in the main thread. This will force the newly spawned thread to execute prior to the main thread.

Second, I added a couple simple println statements so that I could more easily track the progress of the threads.

Here's the output I received:

1
2
Waiting for b to complete...
Total is : 4950

So what does that tell me? Well, the 1 and 2 tell me that the new thread did, in fact, complete processing and invoke the notify() method prior to the main thread getting to the "Waiting for..." line.

However, the fact that I got a "total" value at the end shows that the program did not hang at the second wait() method. Why didn't it hang? I'm not entirely certain - I just know that it didn't.

Perhaps, if only one thread remains (all other threads have terminated), it is automatically notified.

[Murtuza Akhtari]

Perhaps, if only one thread remains (all other threads have terminated), it is automatically notified

In that case Corey, whn i set the priority of Thread b to be the highest, it completed but the main thread did not...inspite of it being the "only" thread remaining...

a question to ponder about ...

[Corey McGlone]

Originally posted by Murtuza Akhtari:


In that case Corey, whn i set the priority of Thread b to be the highest, it completed but the main thread did not...inspite of it being the "only" thread remaining...

a question to ponder about ...

Hmmm...you're right, Murtuza. If you set the priority of Thread b to 10 and leave out the extra wait() that I had inserted, the main thread hangs.

Puzzling.

[David Weitzman]

Yes, ThreadA can wait forever if thread B gets to the synchronized block first. Try inserting a call to Thread.sleep(1000) after thread.start() and see what happens.

Corey, the behavior you're seeing may be related to an issue that has come up here before (I can't find the thread, sorry). Namely, Sun's implementation of Thread synchronizes on and calls notify() on itself! Using a private lock or wait()ing in a loop for a condition will stop that from happening. That might also be a good reason to use notifyAll() here instead of notify().
[ August 10, 2004: Message edited by: David Weitzman ]

[Ernest Friedman-Hill]

To add to what David said: a Thread notify()s itself on exit from run(). This is how join() is implemented: join just wait()s for the notify() that comes when the thread exits (the wait() is in a while loop waiting for isAlive() to become false.)

Honestly, this is a lousy design, and join() should be using a private object for a semaphore -- but now, they can't change it, as some people expect that notify to happen.

[Ilja Preuss]

Of course, the join method is exactly what you should use in this case...

[Jim Yingst]

[EFH]: but now, they can't change it, as some people expect that notify to happen.

Well, given that the behavior is undocumented (as far as I know), I'd say they can change it, and anyone caught unawares by this deserves what they get for relying on undocumented behavior. Then again, I'm in a somewhat grumpy mood from being rained on (and hailed on) during my bike ride home, so perhaps this is influencing my outlook a bit.

[Victor Santos]

Hi ! Thanks everybody for the answers .In the first code I have put here the main thread always complete when i put this code to run , and it was about 100 times sure this is not enought to see Threads behaving diferently , but I had to try ! I stayed about two days to understand this code and this made me feel very unsure . I have few days to improve my knowledge about Threads , I think it will be hard to answer in the real exam , and I think that a person have to be a litle lucky when answering Threads question

[Murtuza Akhtari]

Please read the JLS 17.13 which states this---

If execution of the body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same lock.

So Corey..you were assuming right when you said that whn a thread completes its run method it calls a 'notify()' (of sorts) on itself since it releases the locks.

But somehow it does not work if a priority is assigned to the Thread b.

Any suggestions??