Once again: waiting in a thread loop.

[willemjav]

"Your design seems backwards. Normally the GUI class is instantied first and starts the worker class (to do any init it needs) and then exits to let the GUI engine wait for user input. When the user does something, a listener is called which then calls(via a new Thread) the worker class to do whatever needs to be done."

Yes norm, I already before wrote:

Probably the underlaying mistake of the program is that I did not put the GUI stuff into the top class.

t b c

[Norm]

The comment on recursive call means:
method aa calls method bb which calls aa which calls bb which calls aa and on and on and on.... too many times and the program dies.

[willemjav]

Yes I know about that fact (I learned about it through Davis's Eck book Javanotes 5.0, Section 9.1 -- Recursion ). At first I had the recursive cycle creating new threads.......
But since I am out of both created thread I do not think it is a problem?
Read Ecks stuff, he is not negative about recursive stuff.
I do have to admit that the concept is a little hard to observe (snake eating itselff stuff).

[willemjav]

Today I'll look into your alternative code

[Norm]

I'm not negative about recursion. Normally a recursive routine returns and undoes all the calls that were made.
Your code does NOT return and continues to add new calls going deeper and deeper and deeper.

[willemjav]

The Class containing the GUI stuff should be the public class which goes on top (as you finally showed). I will try to remodel stuff so that, that will be the case. Your code is helpful as a model.

"Normally a recursive routine returns and undoes all the calls that were made."

I do not know how to do that, but I run the applications, together with the recursive loop, many times and did not notice any problem. Of course I cannot look into the machine (It might as well got close to cooking up).

I did actually post a thread about java class design some time ago

http://www.java-forums.org/new-java/...plication.html

I did not get much response (you, norm, where actually the only one responding). I think design is an important issue (nick wrote me that hardwired has some excellent examples).

I wonder what happens when there is a lot of GUI stuff about to happen (buttons, sliders… tons of listeners etc.). It would be confusing to slam it all, in one single public class. So objects should be created and a similar problem (similar to my previous design) occurs. Or would that be the moment one uses interfaces? I know what they are, but actually never programmed one.
I am still not done with the previous examples and so
w.b.c.

[Norm]

With your program requiring manual control, you may not be able to loop enough times for there to be any problem.

I added the following code to the mainSoundblock to show the stack of callsbeing made. There was a variable: cnt that was being incremented as the program progressed, so I chose 1 value at which to dump the stack. The values shown here do not show the recursion. If you were to add the 3 lines of code and choose a larger value than 4, you'll see how the stack builds.

       if(cnt == 4) {      // debug to show recursive calls - NONE with this code
         try{throw new Exception("Show Call Stack");}catch(Exception x){x.printStackTrace();}
            /*  The output from above:
            java.lang.Exception: Show Call Stack
            	at WaitLoops2.mainSoundblock(WaitLoops2.java:97)
            	at WaitLoops2.waitloop(WaitLoops2.java:23)
            	at WaitLoops2.<init>(WaitLoops2.java:123)
            	at WaitLoops2.main(WaitLoops2.java:129)
            */
       }

You can put all the GUI stuff in a single class. A comon program will have a JFrame filled with components. All this can be setup in one class.

Interfaces are used to define a type for an object. A commonly used one is an ActionListener. When a class implements ActionListener that gives the class the type: ActionListener. It can then be used as an arg in a call to addActionListener() which requires an argument of type ActionListener. Since a class can implement more than one interface, it can have more than one type and can be used where objects of those types are required.

[willemjav]

So studying your Waitloop2 class.
There two waitloops, the second is nested into the first and they are not empty (I got the idea).

While (true) {


While (!cont.getstartFlag() {

}

}

The first loop keeps the application going, so by changing the true-boolean for a window listener-boolean-call I could get out of the application and than do some clean up and closing the window?

The nested loop, after exiting, starts the sound tracks (this example is much better than my recursive call, I should admit).

So far so good, but what does actually do the mon (monitor?) object? Why is it an object type? And why is it called monitor?

[Norm]

The Object I called monitor is used to synchronize execution of blocks of code and as a holder for the queueing of threads that are using wait() and notify(). If you read the API doc for Object for those methods it should explain it.

[Nicholas Jordan]

....And why is it called monitor?

It is called that in honor of the person who first described the desired behaviour in cs literature and had the training to do the description in a manner consistent with what was needed. It is called that because that is what he chose to call it. Probably what you should do at this point is study the Barrier code that ftr mentions, I cannot find it right now but it is in this work you are doing and is coded to alleviate numerous difficulties you will encounter trying to solve the "don't know what is going to happen next." because it has what you think of as the actor wait on what is actually the actor.

My approach is designed to run without intervention, making an entry to Console on startup, then exiting if anything touches the keyboard. I call this design approach Headless Monsters Running Through Invisible Doors.

Most people think that is how my mind works, you should be wary of seeing how it actually works.

{ don't fall for it willemjav - it's a setup so I can ask you if you are asking how my mind works or how the code works, carefully re-directing your attention to the code as an ultra-subtle rebuttal .... yuk-yuk }

[willemjav]

found this site about threads and monitors

Thread Synchronization and the Java Monitor

[Nicholas Jordan]

In general, your design reads and int or writes an int. There basically is nothing to wait on other than the clock, which I am sure you have not grasped yet. ( no slight intended ) To do midi push note, you write an int, if you try to schedule next note using wait and notifiy, something has to notifiy at the right time and you have complexified the design needlessly and to no gain. Notifiy all releases all waiting threads, only to find one of them scheduled. It will work for what you are doing, and probably work well, it does not scale. The only thing that waits is the clock, but a thread cannot notifiy it's own code. Thus, we seek the inverse of what Bill is talking about, which would be a sleep(0) or yield. The controller class, if it is the GUI, is already 'sleeping' - that is how GUI's are designed. The amount of time a computer spends doing minior loops like what you have is comparable to a grain of sand on a beach, most people see the beach and move the grains with diesel trucks.

Bjarne Stroustrup's Homepage has given efficient discussion of the matter in Stroustrup: The C++ Programming Language (Third Edition) as well as have several cryptographic authors. Phil states in his handbook from mit press that to have people thinking his software worked and was actually running, it was necessary to put a wait and delay loop that was Lost In Space Classic TV No joke intended, this is basically the core kernel you have to get over, arriving at no way to tell when something will/would happen is the rung that allows one to become a hatchling, raising the head above the deck on a surfaced submarine, one that has been down too long. Between this and what you have been shown so far by others, you would be able to build a complete design already. The site you cite, along with David Eck's code, is not needful. Recursion should not be necessary, nor any great deal of locking. Nor is a bunch of ten pound books bloated with wordy pages. An int will write and read without locks. If you write and int while another thread is trying to read an int, the worst you get is one thousandth of a second on the wrong note, not perceptible to the human auditory.


class clock{
private static final offset;// quarters in midi terminology.
while( runing ){
t2 = current.time();
if( t2 < t1 + offset )sleep(0);
}
else{
t1 = current.time();
doStuff();
}
}
}

That's all the wait and delay that is needful, the sleep(0) is hard to do with wait and notifiy: You then have no control over prioritization. Do not try to lock on two objects, you get what is called the double checked singleton locking bug which does not show up in most testing. Set vars from the controller class - button push - have player read the value. To exit the program, all need be done is set running in the above code to false. To stop playing as in pausing the playing of something without exiting, you just double stack the above code. IOW a for() in a for (), the inner loop is the playMidi(), the outer loop is "while program running"

doStuff();

calls either multitude of instance variables in clock class or you move it to a controller class that takes both the gui controller class and the music data class and gives a reference to it's self to the clock class. That would be where you do a bunch of new's in main, probably in the gui controller class.

[willemjav]

Jeeeeeeesuuuuuuuus nick

[willemjav]

I still try to grasp from norm´s code

Object mon = cont.setstartFlag(false);

and some later
Object mon = new Object();

I am studying threads and notify()/ wait() stuff---- but ok all takes its time.... or not?

[Norm]

wait and notify are one way to serialize two processes so that one does some work and the other waits until the first one is done and notifys the second so that it can do its thing.

You might not need it in your program. The program should be changed so the GUI starts tasks vs the tasks waiting for GUI to move on to do something.

[Nicholas Jordan]

I still try to grasp from norm´s code

Object mon = cont.setstartFlag(false);
// and some later 
Object mon = new Object();

Looks to me like you got it backwards. Like do it the, ahem,... normal way.

In main:

Controller controlller = new Controller( new Sequence( new Playlist()),new Clock(),..

Which is actually not correct in that we have no way to give the clock a ref to (?...)
One approach, assuming as norm suggests, is

Music music = new Music();
Sequence sequence = new Sequence(music);
Controller controller = new Controller(sequence);
// go ahead and start the clock
Clock clock = new Clock(controller);
clock.start();

now when a button push in controller occurs, it is done by the usual awt / swing event protocol, that event does a boolean start / stop / run / play on controller,.. which suprisingly does nothing by it's own code. Only the clock running on the controller actually does anything.

If you think this is difficult, you should try doing baryonic vector calculations on four spin projections (Sz = +3⁄2, Sz = +1⁄2, Sz = −1⁄2, and Sz = −3⁄2), or perhaps some crystal-lattice projections in two dimenstions of observed chaotic transitions in behaviors only observed in one-dimension.

[willemjav]

from David Eck´s book

In Java, mutual exclusion is always associated with an object; we say that the synchronization is "on" that object. For example, the if statement above is "synchronized on tsc." A synchronized instance method, such as those in the class ThreadSafeCounter, is synchronized on the object that contains the instance method. In fact, adding the synchronized modifier to the definition of an instance method is pretty much equivalent to putting the body of the method in a synchronized statement, synchronized(this)*{...}. It is also possible to have synchronized static methods; a synchronized static method is synchronized on a special class object that represents the class that contains the static method.
The real rule of synchronization in Java is: Two threads cannot be synchronized on the same object at the same time; that is, they cannot simultaneously be executing code segments that are synchronized on that object. If one thread is synchronized on an object, and a second thread tries to synchronize on the same object, the second thread is forced to wait until the first thread has finished with the object. This is implemented using something called a lock. Every object has a lock, and that lock can be "held" by only one thread at a time. To enter a synchronized statement or synchronized method, a thread must obtain the associated object's lock. If the lock is available, then the thread obtains the lock and immediately begins executing the synchronized code. It releases the lock after it finishes executing the synchronized code. If Thread*A tries to obtain a lock that is already held by Thread*B, then Thread*A has to wait until Thread*B releases the lock. In fact, Thread*A will go to sleep, and will not be awoken until the lock becomes available.

[Nicholas Jordan]

So what is it you need to lock on?

If you think about it, the state diagram for your work consists of one and only one state. If it is not in that state, that would be a null state. The state your machine exists in is called playNote. Since there is only one note at a time to play, the only other thread we need is the driver. Which in this case is some form of a clock.

Draw the bow back on second section, third chair cello. At some time, bow moves. As it moves, we are playing a note. So are the others, they all happen in synchronization. But since all sections read from the same sheet, in the time domain it is one thread of operation.

[willemjav]

I am still struggling with threads (underestimated that subject). I red the Sun stuff and a useful explanation of the monitor concept at:

Thread Synchronization and the Java Monitor

I order to grasp the principal and to understand the concept, I need to program my own version of the discussed application (backwards-notifying-application).
The main-thread is the GUI panel with its buttons etc. The wait loop and the sounds-tracks (this time without recursive call) happen in a second thread. The notify and wait pair is not implemented in a correct manner, I know!

Exception in thread "Thread-6" java.lang.IllegalMonitorStateException: current thread not owner
at java.lang.Object.wait(Native Method)


In Eck´s book one reads “The general idea is that when a thread calls a wait() method in some object, that thread goes to sleep until the notify() method in the same object is called.” But what object? (I shoud say these things are not explained very well.) So in short: I do understand the concept very well but I do not know how code the wait/ notice part. I do not understand on what I should do the notify and wait (see my code):

public Main() {				// constructor sound tracks
        
        cont = new fboController(10);           // object of the GUI class
        playsound();				// starts the sound thread
        
        System.out.println("constructor main loaded");
}

  

    
private synchronized void playsound()  {
   play = new Playsound();
   play.notify();			// not ok
   play.start();
     
}


class Playsound extends Thread {
  
        public Playsound() {  
            cnt++;                                          // the thread counter
            System.out.println("count wait thread " + cnt); // to see what it is looping
        }
            
            
     
            public void run() {  
                cont.setstartFlag(false);
                cont.selectonoff(true);                  
                while (true)  {		// still do window listener cond
                 
                    do   {
                    	try {
                    		play.wait();			// not ok
                   	 	} catch (InterruptedException ex) {
                        	ex.printStackTrace();
                    	}
                    } while (!cont.getstartFlag()) ;             // wait for start button ||
                     
                         
                    int trc = cont.gettrackNumb();  // read out the track number
                    mainSoundblock(trc);
                    cont.stopclk();
                    cont.ed.resetFbo(); 
   
                }
                //  cont.ed.closeFbo1(); 
               // System.out.println("exit thread " + cnt);
              //System.exit(1);
            }
}


    


private void mainSoundblock(int trck)  {
    cont.ed.resetFbo();
    cont.setescFlag(false);
    trig=false; exit=false;
    if (trck==1 && !cont.getescFlag())  {
    Soundblock1();
   // cont.settrackNumb(trck);
    trck=2;
    }
    
    if (trck==2 && !cont.getescFlag())  {
    Soundblock2();
   // cont.settrackNumb(trck);
    trck=3;
    }
    
    if (trck==3 && !cont.getescFlag())  {
    Soundblock3();
   // cont.settrackNumb(trck);
    trck=4;
    }
    …….  Etc.

[Norm]

current thread not owner

This relates to the "lock" on an object(i called a monitor). A thread MUST have the lock(be the owner) to be able to issue a wait or notify. This can be done by calling the wait in a synchronized method or block.
See previous examples. Read API doc for wait and notify