Re: String von Thread an Programm senden - Stilfrage!
Zitat:
Ob mein Konzept in einer DLL funktioniert kann ich jetzt auf Anhieb nicht sagen. Wenn du von SimpleRWSync ableitest (also einfach nur Critcal Sections verwendest), dann dürfte es kein Problem sein. Eher noch mit der zuerst geposteten Variante ohne Messages. |
Re: String von Thread an Programm senden - Stilfrage!
Wenn du mit einer DDL arbeitest, bastle dir doch einfach selbst ein Semaphor. Das geht recht einfach. Hab sowas in Delphi zwar noch nie gebraucht, aber letztens mal in Java, aber das Prinzip ist natürlich das gleiche.
|
Re: String von Thread an Programm senden - Stilfrage!
Ähm.. was ist das? Die Lösung mit der Message gefällt mir. Aber erkläre mir das doch bitte mal!
|
Re: String von Thread an Programm senden - Stilfrage!
Also ein Semaphore funktioniert vom Prinzip her wie ein Schüsselchen mit Murmeln drin ;-) Immer wenn ein Programmteil einen kritischen Abschnitt, also einen Abschnitt der nie beliebig oft gleichzeitg/nebenläufig ausgeführt werden darf, betreten will geschieht folgendes:
Der laufende Thread schaut nach, ob noch eine Murmel in der Schüssel drin ist, wenn ja, nimmt er sie raus und betritt den kritischen Bereich. Wenn nein, wartet er (entweder aktiv oder besser: passiv), bis wenigstens eine Murmel drin ist. Sobald er den kritischen Abschnitt verlassen hat, legt er diese Murmel zurück. Hast du jetzt ein Schüsselchen mit genau einer Murmel drin, spricht von man von einem binären Semaphor oder auch Mutex. Wenn du willst, kann ich dir mal zeigen, wie man sowas in Java machen würde. In Delphi übersetzen tu ich es aber nicht, geht aber einfach ;-) |
Re: String von Thread an Programm senden - Stilfrage!
Java bringt mir eigentlich jetzt nix. Aber eine Frage. Mache ich das nicht mit der Container-Unit und den BeginRead / BeginWrite bzw. End*? Ich sperre den Zugriff auf die Murmeln so, dass nur einer mit den Murmeln spielen darf. Hat er keinen Bock mehr zu spielen, geb ich den Bereich wieder frei - oder verstehe ich das jetzt falsch?
|
Re: String von Thread an Programm senden - Stilfrage!
Ja, ist schon richtig so. Aber du musst halt aufpassen, dass der Vorgang des Murmel-Rausnehmens und Zurücklegens auf keinen Fall unterbrochen wird, denn dieser Vorgang selbst ist ja keine atomare Aktion und der Scheduler könnte dem Thread genau in dem Moment den Prozessor entziehen, wenn er gerade dabei war, die Murmel zurückzulegen, und dann käme es zu einem Deadlock.
|
Re: String von Thread an Programm senden - Stilfrage!
Halte ich aber für eher unwahrscheinlich. Ist auch keine große Sache die im Thread passiert.
Nur eine Frage zum Beispiel aus dem angehängten Quellcode. Da wurde als Message eine solche verwendet:
Delphi-Quellcode:
Hat das einen speziellen Grund, oder könnte ich auch
const CM_OnChange=WM_User;
Delphi-Quellcode:
benutzen?
const
WM_ThreadChange = WM_USER + 71 Diese Variante mit der Message funktioniert auf jeden Fall! Hab mir grad die Delphi-Hilfe zu Rate gezogen, um die Methoden nachvollziehen zu können |
Re: String von Thread an Programm senden - Stilfrage!
Also so ganz verstehe ich nicht. Warum willst du lieber die 2. Variante benutzen? Und warum sollte es nicht funktionieren? Probier es doch mal aus ;-)
|
Re: String von Thread an Programm senden - Stilfrage!
Das war jetzt wieder so eine Stilfrage. Ich definiere eigene Messages immer so, wie ich es in der 2. Variante geschrieben habe. Hab's halt so gelernt. Deshalb hatte mich die 1.Variante auch etwas verwundert und ich dachte, dass das einen speziellen Grund hat.
|
Re: String von Thread an Programm senden - Stilfrage!
Müsste genauso gehen, wenn du deine 2. Variante benutzt :-) Der Semaphore ist hier übrigens im "beginwrite" (murmel herausnehmen) und "endwrite" (murmel zurücklegen) versteckt :-) Würdest du keine DLL verwenden, ginge es ganz einfach mit Synchronize (funktioniert auch wie ein Semaphor).
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz