Once again: waiting in a thread loop.

[willemjav]

If the the lock object is created in class B
private Object lock = new Object(); // object for common use
and the get method b.getLockObject() returns lock of class B in class A
what am I actually waiting on???
b.getLockObject().wait();
I am very much puzzled that the wait and notifying works in following context (getLockObject().notify() is at class B) there is no relation with the thread p-start() object:

synchronized (getLockObject()) { //use the common lock object
getLockObject().notify();
}

public void run()  {   // run method of class Play
                
                System.out.println("entering in thread " + threadcount);
		
                    synchronized (b.getLockObject()){ 		
			try{				
                          b.getLockObject().wait(); 	
			}
                        catch(InterruptedException e){
                            System.out.println(e);
                        }
                    }
                    soundblock();
                   // this.notify();
                System.out.println("exit thread " + threadcount);
              
        }

[Nicholas Jordan]

this.notifiy is probably not workable code. The wait is accomplished in b.getLockObject().wait - but that is not how you wait - we're getting two issues up on the board here. A lock, as coded, is a synchronization method - which is accomplished by making getLock() synchronized. Further, it has to be:

public synchronized getLock(boolean release){}

You do not notifiy this, notifiy only talks to other - which is not a keyword I have seen except from the Hexagon at Redmond.

Further, you do not get (lock) from waiting thread - you wait() as in second.wait(); which will do all the convoluted work ad hoc. Second is made a variable in First by doing Second second = new Second(); in class First. The this keyword does all the fancy stuff of determining which object is being referenced in a forest of references.

[willemjav]

I think the dummy is finally working.
There is just one do loop
but it goes to sleep and does not spin
The previous idea of class A B
and backwards notifying stands
But next time should be different

package waitthread;

/**
 *
 * @author willemjav
 */

public class A  {
private B b;
private playSoundblock p;
private appLoop loop;
private int threadcount=0;
private Object looplock = new Object();  // object


	

	A()  {  // constructor creates an object of the GUI class B
		b = new B();
                Loop();  // starts the app
               
	}


private void play()  {  // the method that creates the thread object
   
	  p = new playSoundblock();
	  p.start();      
}

private void Loop()  {  // the method that creates the thread object
   
	  loop = new appLoop();
	  loop.start();      
}



private class appLoop extends Thread  {        // the thread that plays the soundblocks
    
    appLoop()  {
    
    }

	public void run()  {
                
                System.out.println("entering in wait thread ");
		while (true) {          // condition can be set by window listener
                    play();             // starts the play thread 
                    b.wakePlaythread();     // the start-button of the soundblock
                    
                    synchronized (looplock){ // while in play thread waitloop sleeps		
			try{				
                          looplock.wait(); 	
			}
                        catch(InterruptedException e){
                            System.out.println(e);
                        }
                    
                    }
                    
                }
                    
               // System.out.println("exit wait thread " + threadcount2);
              
        }
}  // end of wait thread class



private class playSoundblock extends Thread  {        // the thread that plays the soundblocks
    
    playSoundblock()  {
    threadcount++;
    }

	public void run()  {
                
                System.out.println("entering in play thread " + threadcount);
		
                    synchronized (b.getPlaylockObject()){ // play thread waits for start		
			try{				  // to start the soundblock
                          b.getPlaylockObject().wait(); 	
			}
                        catch(InterruptedException e){
                            System.out.println(e);
                        }
                    
                    }
                    soundblock();
                    synchronized (looplock) {  // when exits playthread wakes up waitloop
			looplock.notify(); 		
                    }
                System.out.println("exit play thread " + threadcount);
              
        }
}  // end of play thread class






private void soundblock()  {
    System.out.println("soundblock started");
}  // here is all sound midi data

public static void main(String[] args) {
        new A();
}

}  //and of first public class

package waitthread;

import java.io.IOException;
import javax.swing.JPanel;


public class B  extends JPanel {   // all the GUI stuff of the app.

Boolean flg;
private Object playlock = new Object();  // object for common use


public B()   {
		
              System.out.println("constructor of B loaded");
}

	
        public Object getPlaylockObject(){       // share the app lock
		return playlock;
	}

        public Boolean getflg()  {   // starts the soundblock
            return flg;     
        }
        
        public void wakePlaythread()  {
        try {
            do {                                // simulating start button
            int       d = System.in.read();
           
            }
            while(System.in.available()>0);
        } catch (IOException ex) {
            ex.printStackTrace();
        }
		synchronized (getPlaylockObject()) {  // wakes up play thread
			getPlaylockObject().notify(); 		
		}
        }

} // end of second public class

[Nicholas Jordan]

Wow, constructor starts nested class as a Thread object, then exits with no reference to the thread,... okay ~ okay already, places ref in outer class varaible == good OO probably(!) Class B - which is the Gui thread,......

Gotta quit, I'm gonna bust out the glass in my monitor from laughing.

( seriously - will be back in a while ....)

[willemjav]

The dummy works....... pull it through the compiler and try it out (use the monitor keyboard to get out of the loop)
The application will be closed by setting the do (true) false of the A class. The flag will be set by the B class through a window listener. So the classical
window.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
wont be used here.
Can anybody give me a hint how a window listener works when clossing the app.?

[senthu83]

Hi, hello members. I wish all the best for ypur success.

[willemjav]

thanks, anything else you like to say?

[Nicholas Jordan]

The dummy works.......

unecessarily hard.

pull it through the compiler and try it out (use the monitor keyboard to get out of the loop)

Why?

The application will be closed by setting the do (true) false of the A class. The flag will be set by the B class through a window listener. So the classical window.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); wont be used here.

Discounting proven methods introduces unforseen failure modes.

Can anybody give me a hint how a window listener works when clossing the app.?

How to Write Window Listeners

[willemjav]

I did read that stuff
"How to Write Window Listeners"
But what you do, for instances, when you also want to catch the quit from the menu bar.

Just before quitting the app I need to do some clean up (e.g. disconnecting the midi drivers). Besides the main thread there are two more and I do not know which one is running when the users quits (at any time).... so where to locate the final clause and how I know that that will be called only just before closing the app.
Remember I never did any CS (Computer School)!

[Norm]

catch the quit from the menu bar.

Is that when the user clicks on the close button (X) in the upper right hand corner of the window?
A window listener can be used to catch (and ignore if you want) the clicking on that button.

[willemjav]

when running a java app there are basically two ways to quit
1) the (x) on pc
2) the only menu drop down with the app name (on mac) and choose the quit option
How to catch both options

[willemjav]

quiting a java app.

read this

General: Exit Java applications properly

Define the following action class:

public class Quit extends javax.swing.AbstractAction {
public void actionPerformed(java.awt.event.ActionEvent event) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
System.exit(0);
}
});
}
}

Then attach an instance of this action to the "Quit" button or menu item
just like you would any other action.

If you have a "main" application window, and assuming that it is an instance
of JFrame, you can also try the following:

frame.setDefaultCloseOperation(javax.swing.JFrame. EXIT_ON_CLOSE);

Then, when the frame is closed, the application will exit.

Hope this helps,

Ramesh Gupta
eNode — Powerful XML Infrastructure

[willemjav]

To install your own quite button
still one has to disable the (x) and the quite option
how?

[Norm]

disable the (x) and the quite option
how?

Is the (x) what we see in the upper right of a window?
What is the quit(e) option? Is that on Mac vs windows?
Since some of us are on Windows vs mac, we can't see what you see.
Try writing a very small program with a GUI that has the features that you seem with your GUI. Then run thru the different ways of closing/ending the application, and post them here with your code.
Trapping windowClosing in a listener is one way to handle clicking on the X in the upper right.

[Nicholas Jordan]

This has been discussed in other fora, who arrived at 'cannot be done', which sounds incorrect on the face of it. There should be a WINDOW_EVENT WindowClosing whereby one can do cleanup - a standard hook in a reasonable operating system: Java is too sophisticated not to have one, but we are likely to risk thread cross-lock issues if we go about in frame of observation willemjav is using to code the last posted to which I made discouting observations until it became a safety risk.

willemjav: until you grasp the fundamental nature of threading, you are likely to cross-lock on program exit.

================= <- hardware
||||||||||||||||||||||
||||||||||||||||||||||
||||||||||||||||||||||
numerous threads

if two or greater try to lock on two objects, there must be effective design by systems coders, application coder techniques will generally introduce unforseen failure modes. Maybe we have a mathemetician in the observation pool who can explain this to willemjav.

Envision two post grads, home for vacation, trying to generate Chapter Eleven filing fees by mowing lawns. There are two yards, each with two Gates of Hell. Each is trying to get the other to take a gate but to convey those instructions to the competitor, each must obtain one gate in one yard. Promptly, one grabs the Chrome Gate in Beauford's yard and the other grabs the Golden Gate in the Beatrice's yard, going into a wait state for the competitor to release their FASI approved, tamper-resistant seal.

They can download all the software they want, but it will not release until one of them does a yield(). ( which is correctly coded as sleep(0) )

When will this ever end?

[willemjav]

what is a cross-lock?

On mac I can quit a java app in two ways!
the window (x) (on left side on mac)
and the top menu bar shows the name of the jave app (amung others like apple drop down etc). The menu-drop-down of the java app has a quit option too, so there are two to catch on mac!!!

[willemjav]

I do not even now how to get to the quit-option-one
(the window one sort-of)

[willemjav]

What about this, nick?

 Runtime.getRuntime().addShutdownHook(new Thread() {
	public void run() {
   		System.out.println("calling from hook");
		cleanUp();
	};
        });
        
      



private void cleanUp()  {
     cont.ed.resetFbo();
     cont.ed.closeFbo1();    
     System.out.println(" exit and clean up ");
}

I do not know how, but it works, a secure clean up

[willemjav]

create the thread in the constructor of Main

[Nicholas Jordan]

Dramatic improvement, cross-lock is terminology I came up with. No one is paying the internet to do development, so we get some archaics in contemporary practice. Your last code looks extremely promising, we can discount the two avenues if you use the shutdown hook you posted.

CrossLock is usually called deadlock because of what happens if it happens in the wrong places.