Android Wie richtig auf Threadstatus warten?

[Stroker89]

Angenommen ich habe zwei Threads: WorkerThread und SocketThread
WorkerThread initialisiert und startet den SocketThread im Konstruktur.

Der WorkerThread ist auf die SocketConnection des SocketThreads angewiesen (Output) und soll so lange warten, bis der SocketThread die Verbindung hergestellt hat. Der SocketThread schickt an den Handler des WorkerThreads nach erfolgreicher Verbindung zum Server seinen Status (boolsche Variable).
Im WorkerThread ist jetzt ganz am Anfang der run() eine "leere" WHILE-Schleife, die solange nichts tut, bis eben jene Variable den Zustand TRUE erreicht. Funktioniert soweit auch alles super, nur frage ich mich, ob das die optimalste Lösung ist.

Gibt es andere Möglichkeiten (eventuell Best Practise), oder ist dieser Weg gar nicht so schlecht?

Gruß

 

[Michael...]

Im WorkerThread ist jetzt ganz am Anfang der run() eine WHILE-Schleife, die solange nichts tut, bis eben jene Variable den Zustand TRUE erreicht. Funktioniert soweit auch alles super, nur frage ich mich, ob das die optimalste Lösung ist.

Nein. Das hört sich ein bisschen wirr an.
Warum startet WorkerThread den SocketThread und nicht umgekehrt? Macht meiner Meinung andersrum mehr Sinn.

 

[Stroker89]

Mhhh hätte eventuell erwähnen sollen, dass es sich hier um eine Android App handelt daher dieser Aufbau:

Activity (mehrere) -> Controller (Service) -> ProtocolHandler (Thread) -> SocketConnection (Thread)

ProtocolHandler (WorkerThread wenn man es so nennen möchte) und SocketConnection (SocketThread) sind äquivalent zu den Beispielen im ersten Post.

Da Android die Eigenschaft hat mit einer Activity starten zu wollen hab ich die Initialisierung der Komponenten genau so vorgenommen, wie auch der logische Ablauf der Kommunikation ist.

Hoffe das bringt etwas Licht ins Dunkel

 

[Michael...]

Da Android die Eigenschaft hat mit einer Activity starten zu wollen

Bin leider nicht so firm in Android, aber man kann einen Service auch unabhängig von einer Activity starten, z.B. mittels BroadCastReceiver.
Trotzdem verstehe ich die Reihenfolge nicht:

ProtocolHandler (Thread) -> SocketConnection (Thread)

Was macht ProtocolHandler und soll dieser Thread alle SocketThreads steuern?

 

[Spacerat]

Busy Waiting... wääähhh XD.
Bei Android dürfte wait() und notify() doch mit Sicherheit auch funktionieren.
WorkerThread statret SocketThread (okay, wenns denn so sein soll) und ruft anschliessend seine wait()-Methode auf (!ACHTUNG! nur im synchronized Block möglich). Wenn der SocketThread dann seine Verbindung hat, ruft er (ebenfalls im synchronized Block) <WorkerThread>.notify() auf, damit dieser weiterarbeiten kann.

 

[Stroker89]

Das hört sich doch schonmal gut an. Werde es gleich testen

Vielen Dank

 

[Stroker89]

Hat super funktioniert danke

 

[Aiwendil]

Stroker: offenbar hast du dich noch nicht wirklich mit Multithreading (in JAva) auseinander gesetzt. Das meiste funktioniert dort über message passing und so Wartekonstrukte wie

while(istStatus!=sollStatus) { }

sind allermeistens besser lösbar. Falls nicht sollte aber immerhin noch ein

yield()

in den Schleifenrumpf, womit der Thread seine Rechenzeit abgibt, falls andere Threads gerade wirklich arbeiten und du die Prozessorauslastung nicht unnötig in die Höhe treibst.

Falls du dich damit etwas näher befassen willst empfehle ich dir mal ein paar Skripte/Folien von Unis durchzusehen. (z.B. PVS - Lehre - WS11/12 - Multithreading und Networking im Java-Umfeld)

 

[Stroker89]

Deswegen hab ich ja gefragt ob es eine bessere Lösung gibt
Ist das synchroized wait() nicht in Ordnung?
Vielen dank für deine Links

Gruß

 

[FArt]

Deswegen hab ich ja gefragt ob es eine bessere Lösung gibt
Ist das synchroized wait() nicht in Ordnung?
Vielen dank für deine Links

Gruß

Prinzipiell hast du ein Producer/Consumer Problem zu lösen. Das kann man mit notify/wait sehr gut machen. Heutzutage muss man aber oft nicht mehr selber mit Threads auf diese Art hantieren. Im concurrency Package gibt es für viele Probleme fertige Implementierungen.

Dein Problem könnte man z.B. mit Semaphore (Java 2 Platform SE 5.0) lösen.

 

[maki]

Mhhh hätte eventuell erwähnen sollen, dass es sich hier um eine Android App handelt

.. und das Unterforum ist auch noch falsch, kein Wunder dass du jetzt auch noch JavaSE/EE Ratschläge bekommst

*verschoben*

 

[Spacerat]

.. und das Unterforum ist auch noch falsch, kein Wunder dass du jetzt auch noch JavaSE/EE Ratschläge bekommst

*verschoben*

Gibt es "java.util.concurrent" auf Android überhaupt? Die meisten Konstrukte, die auf "while(warteAufBesseresWetter) { do(garnichts) }" sind BusyWaiting, auch wenn man in diesen Schleifen "Thread.sleep()" oder "Thread.yield()" verwendet.
Nun, "Thread.sleep()" und "Thread.yield()" sind zwar native, aber es würde mich nicht wundern, wenn die VM dafür explizit "<Object>.wait(long millis)" aufruft und "<Object>.notify()" danach intern regelt. Das synchronized "wait()" geht also in Ordnung, "java.util.concurrent" wäre noch ein wenig bequemer (sofern's denn geht) aber Busy Waiting? :noe: :never:

 

[Stroker89]

Gut dann kann ich ja jetzt beruhigt schlafen

Ja mir war schon klar dass, das auf gar keinen Fall geht. Deswegen hab ich ja auch diesen Thread erstellt

Grüße