Thread warten lassen [Erledigt]

[Jan]

Hubert,

nichts anderes erzähle ich die ganze Zeit.

Jan

[brandelh]

Wenn du in Funktion B solange wartest, bis der Thread beendet ist, dann wird sich das Programm so verhalten wie du es erwartest:

Code: Alles auswählen

Function B()
   local oThread
   oThread := Thread():new()
   oThread:start( ??? )
   oThread:synchronize(0)  // hier wird die Funktion B - also der aktuelle Thread angehalten, bis oThread fertig / beendet ist.
return

Achtung: beim Aufruf von :synchronize() darf kein Zeitintervall durch :setInterval() definiert sein. Andernfalls besteht die Möglichkeit, daß :synchronize() nicht mehr beendet werden kann.

Hubert,
nichts anderes erzähle ich die ganze Zeit.
Jan

liest du eigentlich was ich schreibe ?
Wenn ja könntest du mir doch nicht zustimmen und gleichzeitig den Fehler nicht erkennen ... ich versteh nur noch Bahnhof.

[Jan]

Hubert,

nein, nein nein! Warum sollte ich Thread B anhalten wollen??? Das macht keinen Sinn. ICH MUSS THREAD A ANHALTEN!!!

Und Du hast Recht: Ich habe teilweise nicht den Code gelesen. Wenn ich an dem begleitenden Text gesehen habe, daß das der falsche Ansatz ist, dann habe ich mir das erspart. Mea culpa. Ich stehe dazu.

Jan

[brandelh]

Hallo Jan,

lies doch in der Beschreibung der Hilfe nach, laut der müsste so wie ich das geschrieben habe der Thread B den Thread A anhalten.
Aber ich kann es ja nochmal probieren ...

[Jan]

Hubert,

weißt Du eigentlich, wie viele Stunden ich heute die Hilfefunktionen und die Beispiele und diverse pdf von Alaska gelesen habe? Und ich versucht habe, die darin aufgeführten Wege umzusetzen? Entweder ist das zu verkompliziert erläutert, oder ich bin begriffstutzig, oder denke zu kurz, oder eine Kombination aus allem. Jedenfalls habe ich es bis jetzt nicht ans laufen bekommen.

Jan

[brandelh]

Hallo Jan,

zunächst eignet sich deine Aufgabe nicht für Threads, da alles viel zu abhängig voneinander ist !
Zudem ist Threadsteuerung nicht ganz einfach zu verstehen, ich japse auch immer damit

Nun sieh dir den geänderten Code an. Viel wurde nicht geändert, aber die UHR des Threads läuft nun 10 Sekunden,
dann hält sie an und es geht im Hauptprogramm weiter.

PS: es kommt auf die Reihenfolge an

Der weiterlaufende Thread blockiert mit seiner Methode Syncronize(0) den/die anderen Threads

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "inkey.ch"
procedure main()

    cls
    @ 1,1 say "Start von Hauptprogramm - ESC = Ende"

    StarteThread()
    // die Funktion ist zu Ende, der Thread nicht !
    do while inkey(1) # K_ESC
       @10,1 say "Im Hauptprogramm "+time()
    enddo

    quit  // nur QUIT schließt alle offenen Threads !

return

function StarteThread()
   local oThread
   oThread := Thread():new()
   @ 6,1 say "Start von Funktion StarteThread() "+time()
   @ 7,1 say "Hier zeigt der Thread die Uhrzeit an solange er läuft:" color "W+/R"
   oThread:start( "showTime", 7, 60 )
   oThread:synchronize(0)
   @ 8,1 say "Ende  von Funktion StarteThread() "+time()   
return nil

PROCEDURE ShowTime( nRow, nCol )
   local x := 10
   DO WHILE x > 0
      DispOutAt( nRow, nCol, Time() )
      Sleep(100)
      x--
   ENDDO
RETURN

[Jan]

Vielleicht seh ich vor lauter Codegewusel heute nicht mehr klar. Aber wo in Deinem Beispiel wird der erste Thread gestoppt, bis ein zweiter Thread abgearbeitet wird?

Jan

[brandelh]

Du solltest eventuell erstmal drüber schlafen ... und oben meine ROTEN nachträglich eingefügten Bemerkungen lesen

Code: Alles auswählen

function StarteThread()
   local oThread
   oThread := Thread():new()
   @ 6,1 say "Start von Funktion StarteThread() "+time()
   @ 7,1 say "Hier zeigt der Thread die Uhrzeit an solange er läuft:" color "W+/R"
   oThread:start( "showTime", 7, 60 )
   oThread:synchronize(0)
   @ 8,1 say "Ende  von Funktion StarteThread() "+time()   
return nil

oThread:start( "showTime", 7, 60 ) // Thread B startet
oThread:synchronize(0) // Thread B blockiert den/die anderen Threads, bis ER FERTIG IST !

ähnlich wie beim Browser

oBrowse::stabilize() // Browser zur Anzeige zwingen.

[brandelh]

Eventuell wäre es nützlich, beide Beispiele von mir zu speichern, kompilieren, Ergebnis ansehen oder gar debuggen ...

[Jan]

Ich hab das jetzt anders gelöst. Sicher nicht so, wie Alaska sich das gedacht hat, sicher auch nicht sonderlich elegant, aber so klappt es jetzt.

Ich erstelle in der Main eine

Code: Alles auswählen

PUBLIC lRunning := .F.

In Thread A sieht die Schleife jetzt so aus:

Code: Alles auswählen

For i := 1 To nWasAuchImmer
    MEMVAR->lRunning := .T.
    FunktionB()
    Do While MEMVAR->lRunning := .T.
       Sleep(1)
    EndDo
Next

Und ganz am Ende von Funktion B steht

Code: Alles auswählen

MEMVAR->lRunning := .f.

Funktioniert wie gesagt genau so, wie ich es brauche. Und ist flott genug.

Jan

[brandelh]

Hallo Jan,

trotz des Holzhammers solltest du dir meine letzten Zeilen ansehen

Es ist nicht leicht zu verstehen, dass man den Thread den man laufen lassen will mit Synchronize(0) beauftragt, den Rest des Programmes anzuhalten, aber so ist es eben
Die Hilfe könnte in dem Punkt besser sein.

In meinem Beispiel blockiere ich die Funktion B bis der Thread B fertig ist.
Die Funktion B blockiert hierdurch die For Next Schleife und gut ist es.

[Tom]

Code: Alles auswählen

o:=thread():new()
o:start({||ThreadB()})
o:Synchronize(0)

Jetzt wartet der startende Thread darauf, dass ThreadB beendet wird. Wirkt sich bis auf das Event-Handling "herunter" aus, will sagen: Sogar ein nichtmodales Fenster, dass in ThreadB erzeugt wird, "wirkt" modal, wenn das aufrufende Fenster zu A gehört.

Funzt einwandfrei, wie wir im Osten sagen.

[Jan]

Tja, was soll ich dazu sagen? Wenn ich in Thread B ein oThread:synchronize(0) enbaue, dann passiert das hier (hatte ich heute früh schon):

Fehlermeldung synchronize.jpg (33.57 KiB) 5583 mal betrachtet

Jan

[brandelh]

Hi,

in der Funktion, die den ThreadB startet muss das rein, denn diese Funktion wird im aufrufenden Thread ausgeführt, auch wenn es um den gestarteten Thread geht.
Ich habe doch die Beispiele oben, direkt nach oThread:start() kommt oThread:synchronize(0)

[andreas]

Hallo Jan,

im Anhang findest du 3 Beispiele, die meiner Meinung nach dein Problem vollständig mit unterschiedlichen Einsätzen lösen.
Ich habe Signal und Synchronize in den Beispielen verwendet und versucht, die Beispiele so einfach wie möglich zu machen, damit diese leicht verstanden werden können.
Du kannst ja das wählen, was dir am Besten gefällt.

Threads.rar

(11.32 KiB) 172-mal heruntergeladen

[AUGE_OHR]

hi,

warum macht ihr das alle so "kompliziert" ?

Code: Alles auswählen

LOCAL oThread := Thread():new()
LOCAL a,b,c
  a := ""
  b := ""
  c := {""}
  oThread:start( "showTime", a,@b,c )

egal wie ich die Parameter übergebe, "so" bekomme ich nichts "zurück".

PUBLIC lRunning := .F.
...
Do While MEMVAR->lRunning := .T.

also das ist die "ganz harte" Methode ...

was wir doch haben wollen ist eine "Reaktion" des 2nd Thread. Klar ist Signal() dafür gedacht aber auch das "passt" nicht immer ...

Code: Alles auswählen

LOCAL oMain
LOCAL oDialog1     // hier schon initialisieren
LOCAL oDialog2     // könnte auch ein {} sein

   oMain := XbpDialog()...

   oThread1 := Thread():new()
   oThread2 := Thread():new()

   oThread1:start( "tudies", oDialog1 ,oStat1)
   oThread2:start( "tudas",  oDialog2 ,oStat2)

ich gehe mal davon aus das ein Thread (als "Fenster" ) so aussieht.

Code: Alles auswählen

PROCEDURE tudies(oDlg1,oStat1)
LOCAL nEvent, mp1, mp2, oXbp
LOCAL lExit := .F.

  oDlg1 := XbpDialog():new(oStat1 ,, {0,0}, {200,100} )
  oDlg1:title := "Thread 1"
  oDlg1:close := {|| lExit := .T. }
  oDlg1:create()

  nEvent := 0
  DO WHILE !lExit
     nEvent := AppEvent( @mp1, @mp2, @oXbp, 100 )
     DO CASE
//
// hier die Abfragen
//
     OTHERWISE
        oXbp:handleEvent( nEvent, mp1, mp2 )
     ENDCASE
  ENDDO
  oDlg1:destroy()
RETURN

wenn ich oThread:start() aber "so" aufrufe passiert "nichts" ... oDialog1 und oDialog2 sind "leer".

also der nächste Versuch per Referenze @

Code: Alles auswählen

  oThread1:start( "tudies", @oDialog1 ,oStat1)
  oThread2:start( "tudas",  @oDialog2 ,oStat2)

aber auch das bringt nichts.
auch wenn man die Parameter in ein Array "packt" bleibt es "leer".

Quiz Frage : wie wird oThread:start() nun "richtig" angewendet so das ich oDialog1 "zurück" bekomme ? ***

wer das weiss braucht weder Signal() noch meine 3th Lösung : Userdef Event.

Code: Alles auswählen

#define xbeE_Raushier1   xbeP_User+1
#define xbeE_Raushier2   xbeP_User+2

PROCEDURE MAIN

 oThread1:start( "tudies ... oDialog1")
 oThread2:start( "tudas  ... oDialog2")
...
 DO WHILE !lExit
     nEvent := AppEvent( @mp1, @mp2, @oXbp )
     DO CASE
          CASE nEvent = xbeE_Raushier1
               PostAppEvent(xbeE_Raushier1,,,oDialog1)             

          CASE nEvent = xbeE_Raushier2
               PostAppEvent(xbeE_Raushier2,,,oDialog2)             


PROCEDURE tudies(oDlg1,oStat1)
...
  DO WHILE !lExit
     nEvent := AppEvent( @mp1, @mp2, @oXbp, 100 )
     DO CASE
          CASE nEvent = xbe_None
          // warten timeout 4th Parameter
          CASE nEvent = xbeE_Raushier1
...

PROCEDURE tudas (oDlg2,oStat2)
...
   PostAppEvent(xbeE_Raushier)
RETURN

*** klar hab ich die Lösung, aber ich will mal abwarten ob jemand anderes auch auf die Lösung kommt.
@Jan : da ich dir ein Demo geschickt habe bitte ich dich die Lösung noch nicht zu verraten

[Jan]

Ich möchte mich bei Euch bedanken für all de Mühe, die Ihr euch gemacht habt. Aber anscheinend drücke ich mich so verquer aus, das auch nach mehrfachem Wiederholen niemand versteht, wie der Programmablauf eigentlich ist. Oder niemand liest richtig mit, oder meine Ablaufstruktur ist so ungewöhnlich, das niemand dahinter steigt. Auf jeden Fall passt leider keines der Beispiele auf meine Vorgehensweise. Oder ich müsste das gesamte Programm umschreiben, was ich nicht kann, ohne die gesamte Ablaufstruktur des kompletten Programms zu zerstören.

Andreas: Wir können das ja beim nächsten XUG-Treffen besprechen.

Da ich für mich eine Lösung gefunden habe (auch wenn es die Holzhammer-Methode ist), ist der Fall für mich ersteinmal erledigt. Womit ich selbstverständlich die Diskussion nicht abwürgen möchte! Die ist ja durchaus sehr informativ und hilft, die Vorgehensweise bei Threads besser zu verstehen. Also diskutiert das gerne weiter, aber habt bitte Verständnis dafür, das ich mich daraus zurückziehe.

Jan

[brandelh]

Hallo Jan,

dein Holzhammer ist völlig OK, solange dein Programm genau diesen Ablauf hat.
Warum du aber meinst mein obiges zweites Beispiel würde nicht passen verstehe ich nicht.
Du läßt den Code in Thread B deine PUBLIC Variable steuern, weil die Funktion B nicht auf dessen Ende wartet.
Ich habe durch Einfügen einer Zeile (nach dem oThread:START()) die Funktion B auf das Ende von Thread B warten lassen, bevor diese sich beendet:

Code: Alles auswählen

function b()
   local oThread := Thread():new()
   oThread:start( ? )
   oThread:synchronize(0)
return

auf den ersten Blick sieht das blöd aus: 'oThread steuert den Thread B und soll nun den Thread A von Funktion B aufhalten ?'
aber wenn man bedenkt, dass diese Funktion b() und die enthaltene lokale Variable oThread sich selbst ja in Thread A befinden,
wird klarer, warum der Aufruf in Thread A auf die Steuervariable oThread:synchronize(0) von Thread B so wirkt, wie du es brauchst.
Der Thread A meldet an B, dass dieser endlos Zeit hat um seine Arbeit zu erledigen und erst das Ende an den Aufruf in Thread A zurückgibt.
Thread A führt diese Zeile aus, bis die Methode oThread:synchronize(0) von Thread B beendet wird.

Es ist ein bischen wie wenn man "neben sich selbst steht"

[Jan]

Moin Hubert,

wenn ich das mache wie in Deinem Codebeispiel, bekomme ich die Fehlermeldung, die ich weiter oben gepostet habe.

Jan

[AUGE_OHR]

Quiz Frage : wie wird oThread:start()

kleiner Tip : Codeblock !

[brandelh]

Wenn ich in Thread B ein oThread:synchronize(0) enbaue, dann passiert das hier (hatte ich heute früh schon):

Ich hatte aber schon erwähnt, dass das oThread:synchronize(0) nicht im Thread B, sondern in der Funktion B - also im Thread A stehen muss
Wie auch immer, es bestätigt sich meine Aussage, dass wir - zumindest ein Gerüst - deines Quellcodes sehen müssten um dir helfen zu können.

Solange dein Programm diesen Prozess nur einmal startet, geht das mit der Public gut.
Ein MDI Ansatz (also mehr als ein Thread A zur gleichen Zeit) mit einer Public wird hingegen immer scheitern,
weil man einfach nicht weiß, welcher Thread gerade was macht.

Du könntest aber statt der PUBLIC in der MAIN auch eine LOCAL in Thread A erstellen und diese als Parameter per Referenz (@Beendet) an die Funktionen und Threads übergeben.
Diese Lösung wäre dann auch für MDI geeignet.

[AUGE_OHR]

Du könntest aber statt der PUBLIC in der MAIN auch eine LOCAL in Thread A erstellen und diese als Parameter per Referenz (@Beendet) an die Funktionen und Threads übergeben.
Diese Lösung wäre dann auch für MDI geeignet.

aber nur wenn du es in o:Start() auch "richtig" übergibst sonst "wirkt" auch per Referenz nicht.

Code: Alles auswählen

PROCEDURE Main
LOCAL oThread := Thread():new()
LOCAL nRecno := 0
LOCAL nKey

      CLS
      oThread:setInterval(100)
      //  
      // so geht es nicht per Referenz
      //
      oThread:Start( "Test1",@nRecno )

      DO WHILE .T.
           nKey := INKEY(1)
           ? STR(nRecno)
           IF nKey = 27
               EXIT
           ENDIF
      ENDDO
RETURN

PROCEDURE Test1(nRecno)
    nRecno ++
RETURN

und da wären wir wieder bei der Quiz Frage : was muss in o:Start() stehen damit ich was "zurück" bekomme ?

[brandelh]

Der Referenzoperator wird bei der Methode :start() ignoriert.

das hatte ich total vergessen, ich übergebe Objekte (meist SELF, also das Fenster).
Wenn ich im Thread dann oWin:SatzAnzahlAnzeige := nWert setze, wird dies auch sauber im Fenster angezeigt.
Auch das Abbruchflag (iVar des Fensters) kann ich während des Laufs, außen auf .t. setzen und im Thread wird oWin:Abbruch ? abgefragt und reagiert.

Ich mag keine Quiz-Fragen, vermute aber mal du meinst ein Objekt

[UliTs]

Hallo Jimmy,

so kann man Dir nicht helfen!
Du mußt schon genau sagen, welches Problem Du hast!

Uli

[brandelh]

Hallo Uli,

Jimmy hat hier kein Problem, das hatte JAN.
Jimmy liebt aber Quiz-Fragen, er fragt uns