Thread wacht nicht auf

[qwert]

Hallo,

folgender Codeausschnitt:

try {
  System.out.println("schlafen");
  Thread.sleep(Konstanten.SYNCHRONIZER_SLEEP);
  System.out.println("aufwachen");
} catch(InterruptedException err) {
   err.printStackTrace();
}

Ausgabe:

schlafen

Das tatsächliche Programm ist äußerst umfangreich, deswegen kann ich hier kein lauffähiges isoliertes Beispiel posten.
Aber welche Möglichkeiten gibt es, dass der Thread nicht aufwacht? Ich muss zugeben, dass ich "vorsichtshalber" viele "synchronized" verwendet habe . Kann man daraus einen Fall konstruieren, der obiges Verhalten erzeugt?
Mir fällt leider nichts ein .

Vielen Dank!

Edit: Die Variable hat einen Wert von "500".

 

[stg]

Das tatsächliche Programm ist äußerst umfangreich, deswegen kann ich hier kein lauffähiges isoliertes Beispiel posten.

Doch, kannst du, du bist nur zu faul. Mit dem geposteten Codeschnipsel kann man dein Problem jedenfalls nicht nachvollziehen.

 

[qwert]

Zu faul bin ich garantiert nicht, nur kann ich schlecht 1850 Zeilen Quelltext, aufgeteilt auf 17 Klassen posten, denn das würde sich wohl niemand anschauen. Zurechtstutzen geht auch sehr sehr schlecht, denn meine Codestruktur verstehe ich selbst nicht mehr aufgrund mehrerer Threads, Singletons, Observern und ähnlichem.

Also gibt es nicht ein paar Möglichkeiten, die man bei so einem Problem auf jeden Fall mal abchecken sollte?

EDIT: Zu aller erst sollte man mal mehr Geduld haben, denn nach einigen Sekunden wacht der Thread doch auf. Obwohl die CPU-Auslastung sehr gering ist, dauert es aber wesentlich länger als die angegebenen 500ms, auch wenn mir bekannt ist, dass die Angabe eine Mindestdauer ist.

 

[arilou]

Ist sicher, dass der Thread nicht aufwacht, oder erscheint nur die Bildschirmausgabe (

"aufwachen"

) nicht sofort? Der out-Stream ist nämlich gepuffert, und muss nicht sofort erscheinen.
Erweiter' mal den try-Block um

System.out.flush();

denn meine Codestruktur verstehe ich selbst nicht mehr aufgrund mehrerer Threads, Singletons, Observern und ähnlichem.

Das ist schon mal eine ganz schlechte Ausgangslage...

es [dauert] aber wesentlich länger als die angegebenen 500ms, auch wenn mir bekannt ist, dass die Angabe eine Mindestdauer ist.

Eigentlich ist es v.a. eine Höchstdauer, der Thread kann bereits früher (z.B. per notifyAll() ) geweckt werden.

 

[chalkbag]

Eigentlich ist es v.a. eine Höchstdauer, der Thread kann bereits früher (z.B. per notifyAll() ) geweckt werden.

Hi, das wäre mir neu. Ich glaube du meinst das wait bzw. yield, da greift ein Notify. Beim sleep bekommst du den Thread nicht ohne weiters aufgeweckt.
Auch ist es nach meiner Meinung eine Minimaldauer. Es gibt zwar Abweichung aufgrund Systemzeit etc. aber es wird meistens mehr als weniger werden, da der Thread zwar nach den 500ms wieder auf State ready steht, aber deswegen trotzdem nicht sofort die CPU bekommen muss (besonders wenn gerade andere Threads laufen).

Api- Auszug sleep

Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.

Api- Auszug notifyall

Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.

The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.

This method should only be called by a thread that is the owner of this object's monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.

 

[arilou]

Mein Prof im Studium meinte, man müsse bei Thread.sleep immer damit rechnen, dass auch vorzeitig eine InterruptedException kommen könne; ich weis aber nicht mehr, ob er das auf bestimmte Fälle eingeschränkt hat. Auf jeden Fall ist es keine schlechte Idee, stets so etwas zu bauen:

long waitTill = System.currentTimeMillis() + ms_to_wait ;
do{
  long ms_remaining = waitTill - System.currentTimeMillis() ;
  try{
    Thread.sleep( ms_remaining ); }
  catch( InterruptedException iE ) {
    ; }
} while( System.currentTimeMillis() < waitTill );

Evtl. wird's noch stabiler, die InterruptedException durch Throwable auszutauschen. Falls 'ne Scherznase auf die Idee kommt, ms_to_wait negativ zu wählen, oder oder oder.

 

[chalkbag]

@arilou

Jetzt verstehe ich. Gemeint war wahrscheinlich, wenn der Thread frühzeitig abgeschossen/verdrängt wird (systemseitig)?
Danke für die Aufklärung

 

[arilou]

@chalkbag: Ich erinner' mich leider nicht mehr genau, was der Prof genau gesagt hat.
Ich denke eher, dass evtl. manche JVM bei .notifyAll nicht sehr präzise ist, welche Threads sie "weckt" - und eben manche JVM einfach alle weckt, die nicht durch einen synchronized-Lock geblockt sind.
Oder dass manche JVM Probleme hat, wenn mehrere Threads gleichzeitig Thread.sleep aufgerufen haben, und wenn der erste aufwachen will, einfach alle weckt.