Thread-Frage

[Schachmann]

Hallo,

folgendes Problem: Was genau passiert durch das markierte n.wait(); geht an der Stelle der main-Thread schlafen oder der n-Thread? Ich hab schon einiges :rtfm: aber irgendwie sind die Erklärungen alle nur wischi-waschi.
Denn nach meiner momentanen Kenntnislage könnte es doch sein, das nach n.start(); der Scheduler tatsächlich den n.thread laufen lässt, dieser arbeitet die synchronisierte Schleife ab und macht dann das notify(). Aber wo zielt das notify() dann hin? Da der main-Thread ja noch nicht weiter als bis zu dem n.start() gelaufen ist, war er ja noch nicht bei dem n.wait(); Dieses würde der main-Thread dann ja erst abarbeiten, wenn das notify() schon vorbei ist?

Wäre echt toll, wenn jemand eine Erklärung hätte, die es in meinem Hirn klicken lässt...

Gruß,
Ralf

package threadwait;

public class Main {
    public static void main(String[] args) {
        ThreadNotify n=new ThreadNotify();
        n.start();
        
        synchronized(n) {
            try {
                n.wait();                            // Hier liegt der Hund begraben
            } catch(InterruptedException e) { }
        }
        System.out.println("Der letzte Eintrag ist: "+n.last);       
    }
}


class ThreadNotify extends Thread {
    int last;

    public void run() {
        synchronized(this) {
            for(int i=0; i<100;i++) {
                last=i;
            }
            
            notify();
        }
    }
}

 

[Leroy42]

Aber wo zielt das notify() dann hin? Da der main-Thread ja noch nicht weiter als bis zu dem n.start() gelaufen ist, war er ja noch nicht bei dem n.wait();

Falsch!

Das n.start() startet den Thread aber der momentan laufende Thread wird dennoch
weiterabgearbeitet.

Erst nach Erreichen des n.wait() wird der Thread angehalten und durch
das notify() im n-Thread wieder weiter laufen gelassen.

 

[Leroy42]

Dieses würde der main-Thread dann ja erst abarbeiten, wenn das notify() schon vorbei ist?

Nein! Wenn die Schleife im n-Thread zulange bräuchte, käme der
main-Thread erst zu dem n.wait() bevor das notify() aufgerufen
würde.

 

[SlaterB]

am Ende jedes Threads wird übrigens sowieso notifyAll() aufgerufen,

es gibt auch Thread.join(), ganz ohne synchronized-Block + try/catch,
womit ein anderer Thread explitzit auf das Ende des Threads wartet und beliebige notify() zwischendurch ignoriert

 

[Leroy42]

Nochwas zur Klarstellung:

das nach n.start(); der Scheduler tatsächlich den n.thread laufen lässt, dieser arbeitet die synchronisierte Schleife ab und macht dann das notify()[/code]

Richtig! Aber der main-Thread wartet nicht sondern läuft quasi-parallel
nach Aufruf des zweiten Threads (n.start()) weiter!

 

[Schachmann]

Nochwas zur Klarstellung:
Richtig! Aber der main-Thread wartet nicht sondern läuft quasi-parallel
nach Aufruf des zweiten Threads (n.start()) weiter!

Seh ich nicht so. Die sind ja beide am selben Objekt synchronisiert. Wenn die Schleife also mal läuft, müsste der main-Thread blockiert werden, da ja der n-Thread den Lock hat. Oder liege ich da schief?

Gruß,
Ralf

 

[Leroy42]

Uppss! Hast recht!

(Warum ist das "Ich schäme mich" - Smiley nicht mehr da?) 😳

Da bin ich auch überfragt und warte auf SlaterB's Antwort! :bahnhof:

😀

 

[Schachmann]

am Ende jedes Threads wird übrigens sowieso notifyAll() aufgerufen,

es gibt auch Thread.join(), ganz ohne synchronized-Block + try/catch,
womit ein anderer Thread explitzit auf das Ende des Threads wartet und beliebige notify() zwischendurch ignoriert

Das mit notifyAll() stimmt, man kann also das notify() getrost weglassen. Aber es bleibt immer noch meine Frage: Wenn nach dem n.start(); der Scheduler entscheidet den n-Thread wirklich laufen zu lassen, kommt dieser in einen synchronisierten Block. In dem Moment wird also der main-Thread nicht weiterkommen, da ja der n-Thread den Lock hat, dieser läuft also bis zum notify(); und stirbt dann, und erst dann läuft ja der main-Thread wieder und erreicht das n.wait(); Dann kommt aber niemals, niemals, niemals mehr ein notify();

Bin für jeden Tipp dankbar,
Gruß,
Ralf

 

[Leroy42]

und erst dann läuft ja der main-Thread wieder und erreicht das n.wait(); Dann kommt aber niemals, niemals, niemals mehr ein notify();

Vielleich wird dem wait() schon dann genüge getan, wenn das notify()
vorher aufgerufen wurde.

Aber das ist jetzt nur meine Vermutung! :bahnhof:

Ich bin jetzt auch neugierig und warte auf SlaterB's (oder
andere) Antwort/en.

 

[SlaterB]

@Schachmann
die Situation kann so eintreten, ob erst der main-Thread das wait() oder der n-Thread sein Ende erreicht, ist zufallsabhängig,

und ja, das wait() kann dann ewig warten,

was ist aber die Frage?
du könntest im main-Thread abfragen, ob der Thread schon zu Ende ist,
oder wie gesagt join() verwenden, das ist auch sofort zu Ende, wenn der Thread nicht mehr lebt

    public final synchronized void join(long millis) 
    throws InterruptedException {
	long base = System.currentTimeMillis();
	long now = 0;

	if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
	}

	if (millis == 0) {
	    while (isAlive()) {
		wait(0);
	    }
	} else {
	    while (isAlive()) {
		long delay = millis - now;
		if (delay <= 0) {
		    break;
		}
		wait(delay);
		now = System.currentTimeMillis() - base;
	    }
	}
    }

 

[Schachmann]

Naja, das Problem liegt darin, dass mein Dozent behaupt hat, das der Compiler ja den kompletten Sourcecode sieht und schon irgendwie dafür sorgt, dass das wait() vor dem notify() ausgeführt wird. Aber wie konnte er mir auch nicht sagen.
Und ich glaube halt nicht, das der Compiler sich darum kümmert, sondern das es wirklich zufällig ist, welcher Thread zuerst läuft. Im Buch "Das große SCJP-Trainingsbuch" von Ina Brenner wird aber auf Seite 398 ff. auch so getan, als ob 100 %ig gewährleistet ist, dass der main-Thread wartet und der n-Thread dann notify() aufruft.

 

[Leroy42]

Naja, das Problem liegt darin, dass mein Dozent behaupt hat, das der Compiler ja den kompletten Sourcecode sieht und schon irgendwie dafür sorgt, dass das wait() vor dem notify() ausgeführt wird. Aber wie konnte er mir auch nicht sagen.

:shock:

Wovon träumt dein Dozent denn sonstso nachts?
:lol:

Und ich glaube halt nicht, das der Compiler sich darum kümmert, sondern das es wirklich zufällig ist, welcher Thread zuerst läuft.

Stimmt! Das sehe ich genauso! Gebe demnach also
SlaterB's Erklärung Recht!

 

[Gast2]

Naja, das Problem liegt darin, dass mein Dozent behaupt hat, das der Compiler ja den kompletten Sourcecode sieht und schon irgendwie dafür sorgt, dass das wait() vor dem notify() ausgeführt wird. Aber wie konnte er mir auch nicht sagen.

😀 ... schon irgendwie ... ist ja klasse ... wo die immer solche Dozenten ausgraben ... ich finde es schade das in D (?) immer gemecket wird as Informatiker fehlen - bei solchen Dozent ist mir das klar ;( ... gut - sichert meinen Arbeitsplatz

Und ich glaube halt nicht, das der Compiler sich darum kümmert, sondern das es wirklich zufällig ist, welcher Thread zuerst läuft.

na die Wahrscheinlichkeit ist sehr hoch das der Hauptthread zuerst in das wait() stolpert ... der Thread läuft ja bereits ... sollte auf einem Singlecore aber auch zu 100% nicht stimmen !

ab einem Dualcore kann der Hauptthread durch ein Interrupt beendet werden und der Kern macht vor dem wait() einen Kontextwechsel ... der zweite Kern wurde vom BS mit der Abarbeitung des Nebenthread beauftragt und kann auch beginnen (nur Kern 1 ist im Interrupt) ... dann kann es passieren das der NT fertig wird, bevor der HT die Arbeit wieder aufnimmt und in das wait() stolpert ... Nachtrag ... der Hauptthread kann auch ohne Interrupt einem Kontextwechsel folgen, weil einfach die Zeit für diesen Thread abgelaufen ist :bahnhof:

in einem Singlecore hängt es vom BS ab ob der Hauptthread nach dem Interrupt wieder abgearbeitet wird oder ein anderer Thread aus der Schlange geholt ... sollte letzteres der Fall sein, wird erst der Nebenthread abgearbeitet bevor der Hauptthread wieder an der Reihe ist ... von möglichen Kontextwechseln in der CPU mal ganz abgesehen

 

[Leroy42]

À propos:

Diese Vermutung von mir:

Vielleicht wird dem wait() schon dann genüge getan, wenn das notify()
vorher aufgerufen wurde.

nehme ich hiermit offiziell zurück und schäme mich auch gleichzeitig dafür:

(Das "Ich-schäme-mich" - Smiley fehlt mir jetzt wirklich... :bahnhof🙂

 

[Leroy42]

ab einem Quadcore kann der Hauptthread durch ein Interrupt beendet werden und der Kern macht vor dem wait() einen Kontextwechsel ... der zweite Kern wurde vom BS mit der Abarbeitung des Nebenthread beauftragt ...

Also Ergebnis vons Janze:

Brave Programmierer coden sowas nicht! 😛ueh:

(dann kommen sie auch bestimmt in den Himmel! 😀)

 

[Schachmann]

Naja, also wegen mir musst Du Dich wirklich nicht schämen!

Ich danke auf jeden Fall mal allen, die sich über mein kleines Problem Gedanken gemacht haben. Ich sehe es jetzt bis zum Gegenbeweis mal so, dass es tatsächlich ziemlich wahrscheinlich ist, dass das wait(); zuerst läuft, aber eben nicht 100 % sicher.

Danke nochmals,
beste Grüße,
Ralf

 

[Gast2]

Brave Programmierer coden sowas nicht! 😛ueh:

ich weis sowieso nicht wieso alle Welt immer mit Thread-Prioritäten spielen müssen ... kann das BS viel besser ... gut ... es gibt ein paar Ausnahmen wo es Sinn macht einen Thread auf einen Kern festzunageln (aber mehr als zwei fallen mir spontan nicht ein) ... aber an den Prioritäten zu spielen ist sinnlos

 

[Leroy42]

Naja, also wegen mir musst Du Dich wirklich nicht schämen!

Nein! Ich schämte mich wegen meiner

(etwas hirnrissigen) Vermutung aus einem anderen Post:

Vielleich wird dem wait() schon dann genüge getan, wenn das notify()
vorher aufgerufen wurde.