Once again: waiting in a thread loop.

When you are at public class A and you want to notify an event from a second public class B here is what you do:

1) Create an lock object at class B and a getter of the object
2) Situate a notify() on that specific lock at class B
3) Create a waitloop thread at class A with the content lock.wait(), so that the thread goes to sleep until notified from class B

1) private Object whateverLock = new Object(); // for common use
public Object getwhateverLock(){ // share the app lock
return whateverLock;
}
2) synchronized (getwhateverLock()){
getwhateverLock().notify(); // notify the wait thread at class A
}

3) class whateverThread extends Thread

Code:

---

public whateverThread () {  // the constructor
           
        }
            public void run() { 
                  System.out.println(" enter in whatever thread");
                do  {                /
                    synchronized (b. getwhateverLock()){       
                        try{                               
                                          b.getwhateverLock().wait();       
                        }
                        catch(InterruptedException e){
                                            System.out.println(e);
                        }
                   
                    }
                }
            }
        }

---

Of course you have to create an object of class B (b) at class A and you have to create an object for the whateverThread (w) and start it w.start() at class A

Quote:

---

are at public class A and you want to notify an event from a second public class B

---

This sounds exactly like the definition of a listener. class A wants to be notified when SomeEvent happens is class B. So class A calls the class B method: addSomeEventListener(SomeEventListener) where class A implements the SomeEventListener. When class B gets a SomeEvent, then it calls the SomeEventListener method in class A.

Yes norm, that concept is called LEARNING

• Quote:

  ---

  Originally Posted by willemjav

  When you are at public class A and you want to notify an event from a second public class B here is what you do:
  1) Create an lock object at class B and a getter of the object

  ---

  All objects have a monitor, thus will lock() without the need of a lock object, lock objects are for multiple thread techniques that are full of threads running all over the place. This is a comparatively simple locking design here in that we only have one score running at any timeslice. We can wait() on any object a,b,c,d,.. from class FirstClass.
  
  FirstClass may be done as you did in the code I was critical of, we just do A a = new A(); then whenever we have .start()'d 'a' we just do a.wait(); in FirstClass and the code and activities of FirstClass will wait on the code written in class A - all of the callbacks and backwards notifiy and everything are done by simple calling a.wait();
  
  There is nothing further to do.
  
• Quote:

  ---

  Originally Posted by willemjav

  2) Situate a notify() on that specific lock at class B

  ---

  Nope, see 1.
• Quote:

  ---

  Originally Posted by willemjav

  3) Create a waitloop thread at class A with the content lock.wait(), so that the thread goes to sleep until notified from class B

  ---

  Nope, see 1. The only reason you would ever sleep is coded in the GUI class, button pushes are mapped to code calls ( thread dot start ) by the GUI class as an intrinsic.
• Quote:

  ---

  Originally Posted by willemjav

  Code:

  ---

  private Object whateverLock = new Object();  // for common use
            public Object getwhateverLock(){      // share the app lock
        return whateverLock;
        }

  ---

  ---

  Uh,...
• Quote:

  ---

  Originally Posted by willemjav

  Code:

  ---

  synchronized (getwhateverLock()){     
          getwhateverLock().notify();    // notify the wait thread at class A
        }

  ---

  ---

  Uh,... again.
• Quote:

  ---

  Originally Posted by willemjav

  Code:

  ---

  3) class whateverThread extends Thread
      public whateverThread () {  // the constructor
           
        }
            public void run() { 
                  System.out.println(" enter in whatever thread");
                do  {                /
                    synchronized (b. getwhateverLock()){   
            try{               
                                b.getwhateverLock().wait();   
            }
                        catch(InterruptedException e){
                                    System.out.println(e);
                        }
                   
                    }
            }
            }

  ---

  ---

  Uh,... again.

Quote:

---

Originally Posted by willemjav

Of course you have to create an object of class B (b) at class A and you have to create an object for the whateverThread (w) and start it w.start() at class A

---

It is the use of the word whatever here that may allow us to gain traction. Whatever is clearly the nature of a variable. You do not have to create a lock object anywhere, any Java Object has an intrinsic capability of doing a lock() - plus we have the keyword synchronized which may be applied to functions. Objects are not Threads, a Thread is in fact an address held in the processor which does ++ on the address constantly. The code you write is not a Thread, nor is the Thread class.

hi this is sree new to the java forumes...:p

nick, it looks like a interesting criticism. give me a little time to understand what you are saying there.

first question "All objects have a monitor" what this means concerning my code?

This is rather confusing, nick

At the A class there are, besides he main thread, two more threads. Here is the inner class of one of the threads. There is no wait loop, just a wait() clause.

Code:

---

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

---

So you say actually that I should create on object of the A class, at the A class (A a = new A()) and instead of b.getPlaylockObject().wait(); do
a.wait() ?

How do I notify that wait some later, from out the B class ?

could you give an small example of a thread started at class A which waits/ wait() and is again notified/ notify() from out the B class? So I can see what you mean!

Every object has a queue/monitor that can be locked for threads. The locking occurs when the synchronized statement is used. To coordinate two threads, they both must use the SAME object when they do a wait and notify. If one waits in the queue for object X and the other does a notify on object Y, the thread waiting in object X's queue is not effected and will continue to wait.
I posted a small program earlier in this thread that showed that.

Okay norm, your example formed my departure for writing my dummy and accomplishing the pascal to java fbo application using threads to notify and getting rid of empty wait loops. I understand what you are saying and that is what I did in my codes!
But what is nick talking about?

When you synchronize on the same object means that you create a kind of communication line between that object at different spots, right? That is way you can say at one spot obj.wait() and again at some other spot obj.notify(),… so far so good. But what does really happen?
When I put obj.wait() (inside a synchronize method) inside a run() what happens is, that specific thread object goes to sleep (there was an object created of that thread class called thr and started by thr.start()). Just to think that obj.wait() makes only that object to wait and the thread keeps running makes no sense!
Of course if that thread goes to sleep or waits (do not know what is the correct term here) you can not notify the thread some later at that run() method! THE NOTIFY SHOULD BE OUTSIDE OF THAT THREAD !/?
Next ambiguity, what happens when you say just wait()(inside a synchronize method) inside a run() method of a inner thread class. Would that be the same as this.wait() (once an object created and started of that thread class where the run is at) the “this” refers to that object running the thread. If wait()/ this.wait() works! How do you wake-up that waiting thread again, or more concretely, how to notify() the wait!
Still do not come to nick´s Class A, A a = new A(), a.wait() suggestion (I am getting a little dizzy, just a little).

By the way do not be afraid of nick, norm or me...
others might join this searching-thread discussion as well
(there are some very smart java people at this forum.... wake-up
smart.notify())

Quote:

---

obj.wait() makes only that object to wait and the thread keeps running

---

Only threads wait, objects are data.

A thread(not a Thread object) represents an execution path being controlled by the OS. The OS has an instruction location register that keeps track of the instruction that a thread is executing. This register is constantly changing value as the thread processes instruction after instruction. When the thread sleeps, the OS saves the state of the thread including the contents of the register in a control block for that thread. The OS then looks around to see if there is another thread that is ready to execute. If it finds one, it loads that new thread's instruction location into the register and starts it executing.

Well you are still doing a notifiy, but shows progress - definite progress through about 60% of the new code. There is a JSR on what a monitor is ~ but that is only words. It is the actual machine ( virtual machine ) that implements the monitor, and thus is subject to some discussion as to how efficient an implementation is. This efficiency is largely a consequence of what the machine was designed for in the first place.

When moving from one place in the code to another place not the next instruction, all the Instruction Pointer ( ususally a physical register, a'la norms description ) just gets that location as the next location, compiler issue ~ not to be a sidetrack here.

It is like I am at a circus:
The give my a ball (a thread) to straw and catch
the give me an other, an other, and again
keep them up in the air the say....

the problem that causes the cpu to spine is the
private void waitforPedal()..... to get this to wait and notify gets
complicated

Code:

---

public Main() {
 
        cont = new fboController(10);          // input clkpls, cont.ed for fmEdit
        Loop();
       
        Runtime.getRuntime().addShutdownHook(new Thread() {
        public void run() {
                  System.out.println("calling from hook");
                cleanUp();
        };
        });
       
        System.out.println("constructor main loaded");
  }



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

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();     
}



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
                 
                    synchronized (looplock){ // while in play thread waitloop sleeps               
                        try{                               
                          looplock.wait();       
                        }
                        catch(InterruptedException e){
                            System.out.println(e);
                        }
                   
                    }
                   
                }
             
             
        }
}  // end of wait thread class



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

        public void run()  {
               
                System.out.println("entering in play thread " + threadcount);
               
                    synchronized (cont.getPlaylockObject()){ // play thread waits for start               
                        try{                                  // to start the soundblock
                          cont.getPlaylockObject().wait();       
                        }
                        catch(InterruptedException e){
                            System.out.println(e);
                        }
                   
                    }
                    int trc = cont.gettrackNumb();  // read out the track number
                    soundblock(trc);
                    cont.stopclk();
                    cont.ed.resetFbo();
                    synchronized (looplock) {  // when exits playthread wakes up waitloop
                        looplock.notify();               
                    }
                System.out.println("exit play thread " + threadcount);
             
        }
}  // end of play thread class





   
private void waitforPedal() {
    if (!exit) {
        do  {
            // waiting for pedal or keyboard trigger should go in a thread!!!
       
        }while (!cont.getpedFlag() && !cont.getescFlag());  // wait for midipedal
        cont.setpedFlag(false);
        if (cont.getescFlag())  {
            exit=true;              //exit the soundblock
        }
    }
}




private void soundblock(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;
    }
   
    if (trck==4 && !cont.getescFlag())  {
    Soundblock4();
    //cont.settrackNumb(trck);
    trck=5;
    }
   
    if (trck==5 && !cont.getescFlag())  {
    Soundblock5();
  // cont.settrackNumb(trck);
    trck=6;
etc.

---

Showing progress, keep going.

Code:

---

soundblock s = new soundblock();
s.start();
s.wait();

---

There may actually be a need for a notifiy somewhere, I never studied it because I do not code it that way. Here I believe the wait() on a variable named s of type soundblock will do all the waiting and notifiying. Norm can recognize the traditional computer science constructs from the syntax of the Java Language better than I can so probably better he provide guidance on this. Doing so avoids sleeps and yields ( probably )

Code:

---

synchronized (cont.getPlaylockObject())

---

This is not correct.

Code:

---

D d = new D();//
PlaylockObject p = cont.getPlaylockObject();
d.somethingOrOther( p ){}

---

As you have it does not pass what is called a named variable. We can do (p.getSomething()) in the function call that calls this function, think of it as backing up one step in the call chain.

In the code for class D there is a function call named somethingOrOther(Container container ) the variable names do not have to match, this is called scoping.