✔ JVM Bug oder Denkfehler?

[sheel]

Bilderupload: Erweitert Antworten - Büroklammersymbol

Und bitte keine Doppelposts hintereinander vom gleichen User.
Man kann Beiträge doch bearbeiten.

PS: Bei mir funktioniert es auch ohne println...hm...

 

[deepthroat]

Hi.

Und bei mir funktioniert es auch mit println nicht...

Swing ist nicht thread-sicher. Falls man Methoden von einem anderen Thread als dem Swing Event Dispatch Thread aufruft, riskiert man Thread-Interferenz bzw. Speicherkonsistenzprobleme.

Was ist denn das ursprüngliche Problem was du mit dem Einsatz des Threads lösen willst? Funktioniert es denn nicht wenn du setSize aufrufst auch wenn der Frame noch nicht sichtbar ist?

Warum verwendest du nicht einen WindowListener / WindowAdapter? (windowOpened)

Gruß

 

[Cymatoxa]

Hallo,
mein Problem ist etwas komplexer und hat sich theoretisch bereits - durch einen kompletten Umbau - erledigt. Allerdings rätsel ich immernoch, warum diese "Phänomen" auftritt. An den Swing- bzw. ATW-Threads liegt es nicht, es ist selbst mit einem boolean flag das gleiche:

public class WTF {

    static boolean condition = true;

    private static void foo(final int width, final int height) {
        System.out.println("Funktion aufgerufen");
        if (! condition) {
            System.out.println("Funktion ausgeführt");
        } else {
            new Thread() {
                public void run() {
                    System.out.println("Schleife betreten");
                    while (condition) {
                        // System.out.println("Schleife...");
                    }
                    System.out.println("Schleife verlassen");
                    foo(width, height);
                    System.out.println("Thread beendet");
                }
            }.start();
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        foo(300, 200);
        Thread.sleep(5);
        condition = false;
        System.out.println("Variable geandert [condition=false]");
    }
}

Das Programm gibt nur aus

Funktion aufgerufen
Schleife betreten
Variable geandert [condition=false]

und bleibt dann in der Schleife hängen (jedenfalls, wenn System.out.println("Schleife..."); auskommentiert bleibt).
Ich denke mal, dass der compiler den Wert in der Schleife aus performancegründen zwischenspeichert und nicht aktualisiert... Kann das sein? ô.O Ich kenn mich da nicht sonderlich aus...
Danke jedenfalls an euch alle, dass ihr euch für mein Problem die Zeit genommen habt. Vielleicht habt ihr ja noch eine Idee...?

Grüße,
Cymatoxa

 

[sheel]

Das mit den Kompileroptimierungen ist möglich...
das Hauptproblem an deinem boolean ist aber die fehlende Threadsicherheit.
Du machst die Swing-Unzulänglichkeit kein Stück besser,
wenn du ein genau so problematisches bool noch dazu machst.

synchronized-Zugriff wäre schon eher was.

 

[deepthroat]

Du müßtest volatile verwenden:

static volatile boolean condition = true;

Gruß

 

[Cymatoxa]

Du müßtest volatile verwenden:

static volatile boolean condition = true;

Gruß

Sehr cool. So etwas in der Art hatte ich auch im Kopf, bin aber nicht darauf gekommen. Danke!

das Hauptproblem an deinem boolean ist aber die fehlende Threadsicherheit.
Du machst die Swing-Unzulänglichkeit kein Stück besser,
wenn du ein genau so problematisches bool noch dazu machst.
synchronized-Zugriff wäre schon eher was.

Okay, dass AWT nicht threadsicher ist, weiß ich, aber bei Swing bin ich bisher vom Gegenteil ausgegangen. Aber wie kann ein boolean nicht threadsicher sein? Das ist doch nur ein einziges Bit. Und in meinem Programm hat nur ein Thread einen schreibenden Zurgiff darauf...

Grüße,
Cymatoxa

EDIT:
Wie kommt es eigendlich, dass das Programm auf manchen PCs auch ohne volatile funktioniert? Liegt das am Prozessor? Java sollte doch eigendlich auf allen Geräten gleich arbeiten.

 

[sheel]

Swing: Die GUI-Frameworks sind da irgendwie alle gleich.
Ob C/C++, Java, C# ... AWT, Swing oder sonst irgendwas, immer das selbe "Problem".

bool /sicher: Das mit dem einen Bit ist ja alles gut und schön (auch wenn es in den seltensten Fällen wirklich nur ein Bit ist), aber: Da folgt dann wieder die Compileroptimierung usw. darauf.
Alles zusammen ist die ganze Atomic-Sicherheit wieder weg.

Wenn es manchmal ohne funktioniert: Ja, unter Anderem der Prozessor.
Dazu Betriebssystem(evt. auch diese Windowspseudo-HAL), etc...

Wie du sagst, Java soll immer gleich funktionieren.
Nur soll. Mit Java plattformabhängige Programme schreiben ist leider sehr leicht.

 

[deepthroat]

Okay, dass AWT nicht threadsicher ist, weiß ich, aber bei Swing bin ich bisher vom Gegenteil ausgegangen.

A note on thread safety:
It may seem strange that such an important part of the Java platform is not thread safe. It turns out that any attempt to create a thread-safe GUI library faces some fundamental problems. For more on this issue, see the following entry in Graham Hamilton's blog: MultiThreaded toolkits: A failed dream?

Aber wie kann ein boolean nicht threadsicher sein? Das ist doch nur ein einziges Bit.

Das hat mit threadsicher nichts zu tun. Ein Stück Code kann threadsicher sein oder nicht, aber kein Datentyp. Der Datentyp Zugriff kann höchstens atomar erfolgen oder auch nicht...

Und in meinem Programm hat nur ein Thread einen schreibenden Zurgiff darauf...

Deswegen gibt es in deinem Code auch kein Problem mit der Variablen und dem Zugriff darauf an sich.

Wie kommt es eigendlich, dass das Programm auf manchen PCs auch ohne volatile funktioniert? Liegt das am Prozessor?

Ja, z.B. Prozessor. Auf einem Single-Core Prozessor System hat der Prozessor die einzige Kopie einer Variablen, auf einem Multiple-Core / Multi-Prozessor System hat u.U. jeder Prozessor eine Kopie der Variablen. Deswegen muss man den Prozessor mit bestimmten Anweisungen zwingen immer auf die Speicherinformation direkt und nicht auf den (gecachten) lokalen Wert zuzugreifen, damit der Wert immer aktuell gehalten wird.

Java sollte doch eigendlich auf allen Geräten gleich arbeiten.

Es gibt auch in der Java Spezifikation "kann" und "darf" Bestimmungen. Ein Compiler bzw. der Bytecode-Interpreter oder JIT-Compiler kann, bzw. darf bestimmte Dinge (z.B. zur Optimierung) tun, welche letztendlich unter best. Umständen (bei unsauberer Programmierung) zu anderem Verhalten führen.

Er darf z.B. den Wert einer non-volatile Variablen cachen und muss ihn nicht immer aus dem Speicher laden.

Gruß