TThread wird geschlossen
-
Hallo,
wenn ich das hier so lese und mich daran erinnere, wie es mir geht zum Thema Threads (ich hatte es gerade erfolgreich verdrängt)... Vielleicht wäre ein 2. Tutorial zum Thema Threads nicht schlecht. Es gibt ja eins, wo beschrieben ist wie man einen Thread erstellt... Ein fortgeschrittenes, wo beschrieben ist wie man mit Threads arbeitet und vielleicht, wie man die optimal einsetzt - das wär was! Ich würd' ja eins schreiben, aber ich habe KEINE AHNUNG...
Also bleib ich beim Anregen.
MfG
-
Falls diese Aufforderung an mich gehen sollte, muss ich leider sagen, dass ich weder die Zeit, noch das schrifstellerische Talent dazu habe.
Davon abgesehen, wäre vermutlich ein Tutorial unter Verwendung von Botschaften sinnvoller. Wie auch immer, sowohl die Variante mit Botschaften, als auch die mit Events fallen in den WinAPI-Bereich.
-
Deine Ausdrucksweise ist doch brauchbar - man muss ja für n Tutorial nicht schriftstellerische / dichterische Maßstäbe ansetzen (Du glaubst nicht, was ich schon Alles als Tutorial angeboten bekommen habe!); Hauptsache ist doch, dass der Schreiber was von der Materie versteht!
Ansonsten entwickelt sich ja so ein Tutorial - ich kenne jedenfalls kein vernünftiges Tut, welches bereits "in Version 0.1a" vollständig und fehlerfrei war (gut, manche "0.1a Tut's" sind größtenteils kopiert - aber da werden ja auch die Fehler mit übernommen).
Wo und wie jetzt das spezielle Tut hin müsste kann ich nicht beurteilen - mir hätte irgendwie sowas geholfen:"Threads 2: Arbeiten mit Threads / optimaler Einsatz" mit Sachen wie (viell):
Variablen übergeben / Funktionen kreuz und quer aufrufen / weiß nicht / Optimierungen / Spezielle Eigenheiten von Threads / auf keinen Fall dürfen Sie das machen / blabla
Aber was schreibe ich hier, wenn jemand Zeit hätte würde es das wohl schon geben?!
MfG
-
Hallo
Kolumbus schrieb:
"Threads 2: Arbeiten mit Threads / optimaler Einsatz" mit Sachen wie (viell):
Variablen übergeben / Funktionen kreuz und quer aufrufen / weiß nicht / Optimierungen / Spezielle Eigenheiten von Threads / auf keinen Fall dürfen Sie das machen / blabla
Die meisten Sachen die du da sagst sind aber nicht wirklich TThread-spezifisch. Du solltest dir da lieber allgemeine Erläuterungen zum Thema Thread und nebenläufige Programmierung durchlesen. Das ist nämlich erstens Systemspezifisch (WinAPI, Speicher- und Prozeßimplementation allgemein) und zum zweiten sehr umfangreich.
Tutorials sollen im allgemeinen den Einstieg in ein Gebiet erläutern. Aber dieses Thema wäre schon sehr fortgeschritten.
bis bald
akari
-
Hallo,
akari schrieb:
Tutorials sollen im allgemeinen den Einstieg in ein Gebiet erläutern. ...
Das wusste ich nicht. War da bisher anderer Meinung, da ich schon viele sehr spezielle (tiefgehende) Tut's gesehen hab!??
akari schrieb:
Die meisten Sachen die du da sagst sind aber nicht wirklich TThread-spezifisch.
deswegen ja:
Kolumbus schrieb:
Wo und wie jetzt das spezielle Tut hin müsste kann ich nicht beurteilen...
Gut, hätte ich besser so ausgedrückt: Keine Ahnung, ob ein tiefergehendes Tut zum Thema Thread sinnvoll wäre und wo es hin müsste - ...
akari schrieb:
Du solltest dir ... allgemeine Erläuterungen zum Thema Thread und nebenläufige Programmierung durchlesen. Das ist nämlich ... Systemspezifisch (WinAPI, Speicher- und Prozeßimplementation allgemein)...
Gut das mal so deutlich gelesen zu haben, im Ernst.
MfG
PS: Mal ne persönliche Frage @akari: Wo entspringt eigentlich Dein Nick? hab da so ne Theorie...
Ich nehm's nicht persönlich wenn Du darauf nicht antwortest.
-
Hallo
Das Problem bei einem weitergehendes Thread-Tutorial hier im BCB-Forum wäre das es in drei Ebenen aufgeteilt sein müßte :
- Die Theorie
- Die Windows-spezifische Umsetzung, Besonderheiten unter Windows, WinAPI
- Die Kapselung der Windows-Thread in der VCl mit TThread.
Und dabei ist der letzte Punkt noch der einfachste und kürzeste.Zum zweiten Punkt kannst du Nachforschungen im WinAPI-Forum oder in der MSDN anstellen, du wirst merken das da einiges zu lesen ist.
Und zum ersten Punkt kannst du Skripte aus Unis oder Sachbücher lesen.Mein Nick ist eine Weiterverwendung eines Namens meines alten RPG-Charakters. Ja ich weiß mittlerweile das eigentlich ein weiblicher Name ist
bis bald
akari
-
ok.. b2t ^^
ich hab noch eine frage:
mit CreateEvent kann man ja nur einen String (bzw. char*) mit übergeben an das Event... Wie soll ich dann aber zum Beispiel nen Socket übergeben? Macht man da noch nen Array und speichert das so, dass man halt ne Art ID mit an das Event übergibt und dan im Array sucht, was eigtl mit übergeben wird?
dann können ja auch 3 zur gleichen zeit connecten... wie macht man das am blödesten mit den events - wenn ich nur ein handle dafür hätte würd ich es ja einfach überschreiben - da hatte irgendwer mal kurz Semaphores gesagt... Aber irgendwie konnte ich nirgendwo richtig finden, WIE es geht... Was das ist weiß ich denke jz schon so halbwegs ^^
Und noch ein was:
Ich hab ja ne Klasse von TThread abgeleitet, hab die Execute-Prozedur komplett blockiert mit dem WaitForMultipleObjects in ner Endlosschleife... Wenn die Klasse aber noch andere Funktionen hat (zum Beispiel erst mal die Events, die von dem Socket ausgehen, wo ich dann das WinAPI-Event auslöse) - geht das überhaupt? Direkt kann man das ja nicht machen, oder? Weil der Socket ja als Event nur ne Funktion bzw. Prozedur akzeptiert...Irgendwie stell ich mich gerad bissl doof an ^^
Danke schon mal
-
Ohne die Anwendungslogik zu kennen, ist es schwer etwas dazu zu sagen. Normalerweise sollte man versuchen, Daten bereits beim Erstellen des Threads mit zu übergeben (Konstruktor erweitern).
Ist diese Vorgehensweise nicht möglich, würde ich eher dazu tendieren, die zu bearbeitenden Objekte in der Anwendung, also z.B. im MainForm zu verwalten und den/die Thread(s) die Objekte holen zu lassen. Der Thread muss dann nur informiert werden, dass es neue Arbeit gibt (Event oder Semaphore). Hierbei muss allerdings ein Zugriffsschutz verwendet werden. Möglicherweise reicht dazu eine TThreadList aus.
-
Hi nochmal @akari,
um die Sache zu vervollständigen: Da ich meine Nick's immer aus dem real-life beziehe, hatte ich ne andere Theorie: akari hatte als kleiner Lausebengel ne Spielekonsole und konnte deren Namen nicht korrekt aussprechen. Und so wurde schon in frühen Jahren aus einem allseits bekannten Atari der im Forum bekannte "akari"...
Das mit dem Mädchennamen wusste ich übrigens auch nicht, aber jetzt wo Du's so sagst...MfG
-
Hallo
Nein ich hatte nie einen Atari.
Das reicht aber jetzt an Offtopic.bis bald
akari
-
"Ohne die Anwendungslogik zu kennen, ist es schwer etwas dazu zu sagen. Normalerweise sollte man versuchen, Daten bereits beim Erstellen des Threads mit zu übergeben (Konstruktor erweitern)."
Das mach ich ja... Ich erstelle ihn und übergebe die nötigen Parameter (sind aber nur sehr wenige (einer oder maximal noch zwei)... Der Rest an Parametern (bzw. Arrays) wird im Thread erstellt und verwaltet...
"Der Thread muss dann nur informiert werden, dass es neue Arbeit gibt (Event oder Semaphore)" Nun war genau das die Frage, was besser ist, wenn ich nen Socket drin hab und dem zu Folge können ja auch mehrere Clients zu gleich verbinden (also nehm ich ja mal an, dass Semaphores besser sind, wär nur noch die Frage, wie das funktioniert... Mir würden ja einfach nen paar Befehle dazu reichen und ich guck den Rest selbst nach, aber so weiß ich nicht mal, wo ich anfangen soll zu suchen - zum googlen bin ich irgendwie zu blöd... ).
"Hierbei muss allerdings ein Zugriffsschutz verwendet werden." Den brauch ich ja nur bei Schreibzugriffen, nicht beim Lesen - das fällt also komplett weg und wenn nicht, dann werd ich das schon selbst hinbekommen...
Jetzt steht aber noch immer meine Frage im Raum, wenn ich ne Klasse erstelle und von TThread ableite, wie verhält sich das dann, wenn ich Execute mit WaitFor... blockiere und aber nen Event ausgelöst haben will (zum bsp. beim OnConnect), kann ich da ja nicht direkt nen API-Event übergeben - brauch ich also erst ne Funktion, die das API-Event auslöst und beim Borland-Event gestartet wird...Danke schon mal