PureBoard

Verfasst: **26.08.2006 15:31**

Kapier ich das jetzt richtig?

- Der Computer hat so eine Art Sklavengalerentrommler.

- Und zwischem jedem 4. und 5. Schlag, darf mein Programm irgendwas machen.
- Danach sind die anderen Programme an der Reihe.
- Und die Tastatur und der Bildschirm/Graphikkarte haben einen anderen Trommler.
- Mit einem Thread erlaube ich einer Funktion nach einem anderen Takt zu arbeiten um z.B. die Information, dass die Enter-Taste gedrückt wurde zu bekommen bevor mein Hauptprogramm eigentlich an der Reihe ist.

Wahrscheinlich nicht...

Hab ich, wenn ich so was wie Space Invaders programmiere überhaupt Verwendung für Threads?
Oder bei komplizierten mathematischen Rechnungen oder KI-Zeug?

Verfasst: **26.08.2006 15:53**

Deine Beschreibung gefällt mir, so ist es in etwa richtig.

Verwendung haste erst dann, wenn etwas furchbar lange braucht, der Rest
des Programmes aber trotzdem nutzbar bleiben soll und unabhängig von
diesem furchbar langem noch sinnvoll einsetzbar ist

Verfasst: **26.08.2006 16:06**

Ich schon mal gesehen, dass man währen der Ladezeit von einem umfangreichen Spiel sich die Zeit mit einem Pong-Klon vertreiben konnte.
Das wäre eine Anwendung für Threads, oder?

Mal Konkret: Ich will für ein Dame Programm eine Datei mit einer Liste aller Möglichen Spiele machen.
Ist das überhaupt mit der Rechenleistung eines Computers möglich?
Ich würde mir dann eine Funktion schreiben, die erstmal alle möglichen Züge in ein Array schreibt und dann einen ausführt und in einem Thread würde dann die nächste Zugmöglichkeit ausprobiert werden.

Irgendwie so. Und die Funktion ruft sich immer wieder selbst auf.

Damit kann man doch DEN perfekten Dame-KI-Spieler machen.

//Könnte man auch ohne Threads, aber so könnte es schneller und einfacher gehen.

Verfasst: **26.08.2006 16:16**

ups:

Wikipedia hat geschrieben:Heute auf PCs laufende Programme können eigentlich nicht mehr gegen menschliche Gegner verlieren. Allerdings gibt es heute nur noch wenige große Meister im Damespiel, so dass Vergleiche mit der Spielstärke der 1980er und 1990er Jahre schwer sind. Auch aufgrund der absoluten Überlegenheit des Computers im Damespiel finden sich nur wenige Nachwuchsspieler. Cake Manchester nahm auch an der Computer-Dame Weltmeisterschaft 2002 in Las Vegas teil. Es siegte dort Nemesis vor KingsRow und Cake. Es ist ein verbreitetes Missverständnis, dass das Damespiel ein vollständig analysiertes, gelöstes Spiel sei. Man vermutet, dass das Damespiel etwa 10^18 Stellungen besitzt. Eine vollständige Lösung des Spiels wird noch vor dem Jahre 2010 erwartet. Derzeit arbeiten Jonathan Schaeffer und seine Kollegen vom Chinook-Projekt daran. Im August 2004 gelang ihnen ein Teilerfolg: Eine bestimmte Eröffnung (der White Doctor) wurde als unentschieden bewiesen. Das Programm Chinook wird nun mit dieser Kenntnis in dieser Eröffnung nicht mehr verlieren, und immer dann gewinnen, wenn der Gegner einen Fehler macht.

Und ich hab schon gedacht, dass ich das mit Schach machen kann.

Verfasst: **26.08.2006 16:55**

ich würde es (theoretisch!) vorher berechnen und in einer datei mitgeben, oder zur init-time berechnen.
zur laufzeit des eigentlichen games sollte die KI nur noch auf die tabelle zugreifen.
(wenn du ne tabellen-KI anstrebst, was ja der fall zu sein scheint.)
wird aber an der gesamtmenge scheitern.

10^18 * tabelle für die feldstellungen (à 16byte) ist halt doch im terabyte-bereich.

wenn du einen effektiven algorithmus für das berechnen der möglichen folgestellungen hast,
und das programm praktisch immer die nächsten 10 züge vorausberechnet, könnte das eher reinpassen.
(ich geh jetzt halt mal wirklich von dem raumproblem aus, nicht vom algo-problem)

die berechnung in einen thread zu packen, kann hier nur etwas die bedienfreundlichkeit verbessern,
da der spieler schon während der rechner die nächstmöglichen züge berechnet, die GUI bedienen könnte.

also:
start->computer berechnet die möglichen eröffnungen auf 10 züge tiefe->
player spielt->computer wählt den adequaten zug aus der tabelle->
computer zeigt seinen zug an und gibt die GUI für den player frei->
computer berechnet die möglichen folgezüge auf die angesagte tiefe

Verfasst: **26.08.2006 20:36**

Ich arbeite eigendlich gerne mit Threads. Ein problem ist die Syncronisation der Threads. Dafür nehme ich Gobale Variablen da diese von allen Thread erreichbar sind. Für diese Aussage bekommen ich bestimmt einen auf den Deckel. Dabei ist nur im Vorfeld festzulegen wann welcher Thread auf welche Variable schreiben darf. Oder Variable A darf nur von Thread A beschrieben werden und von allen anderen gelesen werden, usw.

Beispiel Hauptprogramm erst beenden wenn Thread beendet hat.

Code: Alles auswählen

Global exit = 0

Procedure Info(text.s)
  temp.s = FormatDate("%YYYY.%MM.%DD %HH:%II:%SS | ", Date()) + text
  AddGadgetItem(0,-1, temp)
EndProcedure

Procedure MyThread(ID)
  
  Info("Starte Thread...")
  Repeat
    ; Zyklischer Code
    Delay(10)
  Until exit = 1
  ; Code vor beenden
  Info("Beende Thread...")
  Delay(1000)
  Info("Fertig.")
  exit = 2
  
EndProcedure

If OpenWindow(0, 10,10,640,480, "Test")
  CreateGadgetList(WindowID(0))
    ListViewGadget(0,0,0,640,480)
    
  hThread = CreateThread(@MyThread(), 1)
    
  Repeat
    event = WaitWindowEvent()
    Select event
      Case #PB_Event_CloseWindow
        If exit = 0
          exit = 1
        EndIf
    EndSelect
  Until exit = 2
  Delay(1000)
EndIf

Verfasst: **27.08.2006 00:02**

Kaeru Gaman hat geschrieben: die berechnung in einen thread zu packen, kann hier nur etwas die bedienfreundlichkeit verbessern,
da der spieler schon während der rechner die nächstmöglichen züge berechnet, die GUI bedienen könnte.

Ja-Nee

Also Threads bei der Erstellung dieser Datei zu benutzen (natürlich ohne GUI) würde nichts bringen (?).
Ein Thread ist also kein Wunder-Geschwindigkeitsverbesserer (?).

Verfasst: **27.08.2006 12:30**

obbba hat geschrieben:Ein Thread ist also kein Wunder-Geschwindigkeitsverbesserer (?).

nein, wie denn auch.

du müsstest ja MEHR zeit in deiner zeitscheibe haben.
aber ein thread kann eben nur etwas parallel machen, und dafür dieselbe zeitscheibe nutzen.

außerdem müsste man ja einen rechenprozess in mehrere gleichzeitig ablaufende
vorgänge aufteilen, damit threads teile davon übernehmen könnten.
da wird klar, dass es nur wenige spezielle sachen gibt,
wo eine parallelverarbeitung etwas bewirken kann.
die meisten algorithmen (wie z.b. sortieren) müssen in einem geschlossenen prozess ablaufen.

sorry für meine holprige sprache heute. ich tippe mit der linken, deshalb viel langsamer als ich denke.

Verfasst: **27.08.2006 13:13**

Warum tippst du denn mit der Linken?

Hast du Aua an der Rechten gemacht?

Sorry für meine Sparache, habe einen kleinen Bruder.

Verfasst: **27.08.2006 13:33**

ich bin gestern beim irisch tanzen hingefallen...

hoffe, die flosse is nur gestaucht, nich gebrochen...

danke für deine aufmerksamkeit.....

PureBoard

Wie funktionieren Threads?